TEMA III - Control de Acceso - Ago-Dic 2021

ISC
Apuntes de TBD Instituto Tecnológico de Ciudad Madero

M.C. Martha Laura Chuey Rubio
TEMA III
CONTROL DE ACCESO
INTRODUCCIÓN.
ACTIVIDAD INTRODUCCIÓN. Acceder a las siguientes dirección de internet e intercambiar ideas

con los compañeros de clase (en el Foro en el Canal Tema 3 – Control de Acceso), plantear por
escrito sus conclusiones y comentarios sobre lo que argumentaron sus compañeros, (Tarea 1)
a) Seguridad de datos: En qué consiste y qué es importante en tu empresa

https://www.powerdata.es/seguridad-de-
datos#:~:text=En%20l%C3%ADneas%20generales%2C%20seguridad%20de,datos%20de%20una%20posibl
e%20corrupci%C3%B3n.
b) La estrategia de seguridad en las bases de datos

https://www.ambit-bst.com/blog/la-estrategia-de-seguridad-en-las-bases-de-datos
3.1 TIPOS DE USUARIOS.

Un usuario es todo aquel que tenga contacto con el sistema de base de datos. Se tienen tres clases generales
de usuarios:
1. Programador de aplicaciones.
• Usuario sofisticado: interactúa con el sistema sin escribir programas. Genera consultas en un
lenguaje de base de datos.
• Usuario especializado: algunos usuarios sofisticados desarrollan aplicaciones de base de
datos especializadas. Entre estas aplicaciones se encuentran los sistemas de diseño asistido
por computadora.
• Usuarios ingenuos: es el usuario final que utiliza bases de datos sin saberlo, para él es
totalmente transparente como se generan las consultas de la información.
2. Quienes diseñan y participan en el mantenimiento de una base de datos se les clasifica como
Actores en el escenario y Trabajadores tras bambalinas.
• Actores en el escenario: personas que su trabajo depende del uso constante de una base de
datos.
• DataBase Administrators (DBA): administra dos recursos: 1) la base de datos y 2) SGBD y el
software relacionado; autoriza el acceso a la base de datos; vigila el uso y adquisición del
hardware y software necesarios para su uso; también es el responsable de velar por su
seguridad y lentitud en el sistema.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
Agosto - Diciembre 2021
ISC
• Diseñador de base de datos: es el encargado de estructurar la arquitectura para representar y

almacenar los datos. Él debe atender a los usuarios de la base datos para comprender sus
necesidades presentando un diseño que dé respuesta a sus necesidades.
• Usuarios finales: son quienes requiere acceso a la base de datos para generar consultas e
informes. Hay varios usuarios finales como son:
❖ Usuarios finales esporádicos: acceden de vez en cuando pero esto no significa que
siempre requieran la misma información.
❖ Usuarios finales simples o paramétricos: su función gira en torno a consultas y
actualizaciones de la base de datos: todos estamos acostumbrados a tratar con estos
usuarios, como los cajeros bancarios al revisar los saldos, al generar retiros y depósitos.
❖ Usuarios finales avanzados: estos son ingenieros, analistas de negocios, científicos, son
quienes conocen los recursos del SGBD para satisfacer requerimientos complejos.
❖ Usuarios autónomos: utilizan base de datos personalizadas basadas en programas
comerciales que cuentan con interfaces de fácil uso.
• Analista de sistemas y programadores de aplicaciones: determinan los requerimientos de los
usuarios finales.
• Trabajadores tras bambalinas: están para mantener el sistema de base de datos.
3. Diseñadores e implementadores del SGBD: se encarga de diseñar e implementar los módulos e

interfaces del SGBD. Un Sistema de Gestión de Base de Datos consta de varios componentes y
módulos.
3.1.1 Administrador de Base de Datos (ABD) y la seguridad en base de datos.
El ABD es el responsable principal de la gestión de un sistema de base datos. Entre las responsabilidades del
ABD se encuentran la concesión y retirada de privilegios a los usuarios que necesitan utilizar el sistema, la
clasificación de usuarios y datos en función de la política de la organización. El ABD dispone de una cuenta
de ABD en el SGBD, llamada también a veces cuenta de sistema o de superusuario, que proporciona
enormes posibilidades que no están disponibles para las cuentas y los usuarios normales de la base de datos
(esta cuenta es similar a las cuentas de tipo root (raíz) o superuser (superusuario) que pertenecen a los
administradores de sistemas y permite el acceso a comandos del sistema operativo). Entre los comandos
privilegiados a nivel del ABD se encuentran los comandos para conceder o retirar privilegios a las cuentas o
usuarios individuales o a los grupos de usuarios y para ejecutar los siguientes tipos de acciones:
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
1. Creación de cuentas. Mediante esta acción se crea una nueva cuenta y contraseña para posibilitar el
acceso al SGBD a un usuario o grupo de usuarios.
2. Concesión de privilegios. Esta acción permite al ABD conceder determinados permisos a
determinadas cuentas.
3. Retirada de privilegios. Esta acción permite al ABD retirar (cancelar) determinados permisos
concedidos previamente a determinadas cuentas.
4. Asignación del nivel de seguridad. Esta acción consiste en asignar cuentas de usuario al nivel de
clasificación de seguridad adecuado.
El ABD es el responsable de la seguridad general del sistema de bases de datos; la acción 1 de la lista anterior
se utiliza para controlar el acceso al SGBD en su totalidad, mientras que las acciones 2 y 3 se utilizan para
controlar las autorizaciones discrecionales en la base de datos y la acción 4 se utiliza para controlar la
autorización obligatoria.
Siempre que una persona o grupo de personas necesitan acceder a un sistema de base de datos, ese individuo
o grupo deben solicitar, en primer lugar, una cuenta de usuario. El ABD creará entonces una cuenta de
usuario y una contraseña nuevas para el usuario si existe la necesidad legitimada de su acceso a la base de
datos. El usuario deberá iniciar sesión en el SGBD introduciendo el número de cuenta y la contraseña cada
vez que necesite acceso a la base de datos. El SGBD comprueba que el número de cuenta y la contraseña
son validos; si lo son, se permite que el usuario utilice el SGBD y acceda a la base de datos. También se
puede considerar a los programas de aplicación como usuarios y se les podrá solicitar la contraseña.
Resulta sencillo seguir la pista a los usuarios de la base de datos y a sus cuentas y contraseñas mediante la
creación de una tabla cifrada o archivo con dos campos: Cuenta de usuario y Contraseña. El SGBD puede
realizar el mantenimiento de esta tabla de una forma muy sencilla. Cada vez que se cree una nueva cuenta,
se insertará un registro en la tabla. Cuando una cuenta sea cancelada, el registro correspondiente debe ser
borrado de la tabla.
El sistema de base de datos también debe seguir el rastro de todas las operaciones en la base de datos que
un usuario determinado realice durante cada sesión, que comprende toda la secuencia de interacciones
realizadas por ese usuario en la base de datos el momento en que inicia la sesión hasta el momento en que
finaliza. Cuando un usuario inicia una sesión, el SGBD puede registrar el número de cuenta del usuario y
asociarlo a la terminal desde el cual el usuario abrió la sesión. Todas las operaciones desde esa terminal se
asignarán a la cuenta del usuario hasta que éste cierre la sesión. Es particularmente importante seguir el
rastro a las operaciones de cada actualización que se realicen sobre la base de datos, de modo que el ABD
pueda determinar qué usuario provocó el daño en el caso de que la base de datos sea modificada en forma
malintencionada.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Para mantener un registro de todas las actualizaciones realizadas en la base de datos y de los usuarios en
particular que realizaron cada actualización, se puede modificar le registro de sucesos del sistema (system
log). Recuerde que el registro (de sucesos) del sistema incluye una entrada por cada operación realizada
sobre la base de datos que se pueda necesitar en caso de fallo transaccional o de caída del sistema. Es
posible expandir las entradas del registro en forma que incluyan también en el registro el número de cuenta del
usuario y el identificador de la terminal desde el que se realizó la operación. Si se sospecha de alguna
modificación malintencionada, se realizará una auditoría de la base de datos, que consiste en la revisión del
archivo de registro para examinar todos los sucesos y operaciones realizadas sobre la base de datos durante
un determinado período de tiempo. Cuando se encuentre una operación ilegal o no autorizada, el ABD podrá
determinar el número de la cuenta utilizado para realizar la operación. Las auditorías en la base de datos son
particularmente importantes en el caso de base de datos con información confidencial que sean actualizadas
por un gran número de transacciones y usuarios, como una base de datos bancaria actualizada por un gran
número de cajeros del banco. A un registro de una base de datos que se utilice principalmente para propósitos
de seguridad se le llama, en ocasiones, registro de auditoría.
3.1.2 Impactos organizacionales de la tecnología de Base de datos.
Debido a la amplia presencia de las bases de datos, existen distintas formas en las que se puede interactuar
con ellas. La clasificación de la figura 3.1, muestra las diferencias entre los usuarios funcionales, quienes
interactúan con las bases de datos como parte de su trabajo, y los profesionales de los sistemas de información
quienes participan en su diseño e implementación. Cada elemento de la jerarquía representa un rol que se
puede jugar; aunque puede jugarse más de uno de forma simultánea. Por ejemplo, un usuario funcional con
un trabajo como analista financiero puede jugar los tres roles en distintas bases de datos. En algunas
organizaciones se traslapan la diferencia entre usuarios funcionales y profesionales de la información. En
estas organizaciones, los usuarios funcionales pueden participar en el diseño y uso de las bases de datos.
Los usuarios funcionales pueden desempeñar un papel pasivo o activo cuando interactúan con las bases de
datos. El uso directo de una base de datos es un rol pasivo. A un usuario indirecto se le ofrece un reporte
de algunos datos extraídos de una base de datos. Un usuario paramétrico es más activo que un usuario
indirecto. Un usuario paramétrico solicita formularios existentes o reportes con el uso de parámetros, valores
de entrada que cambian de un uso a otro. Por ejemplo, un parámetro pude indicar un rango de fechas, un
territorio de ventas o el nombre de un departamento. El usuario experimentado, es el más activo.
Debido a que la necesidad de toma de decisiones no se puede predecir, es importante dominar el uso no
planeado de una base de datos. Un usuario experimentado es lo suficientemente hábil como para construir un
formulario o un reporte cuando lo necesite. Los usuarios con experiencia deben comprender perfectamente
los accesos no procedurales.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Especialización
Usuario Sistemas de
funcional información
Analista
Indirecto Paramétrico Poderoso ABD Administración
Programador
No Técnico Técnico
Figura 3.1 Clasificación de roles.
Los profesionales en sistemas de información interactúan con las bases de datos como parte del desarrollo de
un sistema de información. Los analistas/programadores son responsables de obtener los requerimientos,
diseñar las aplicaciones e implementar los sistemas de información. Ellos crean y usan vistas externas para
desarrollar formularios, reportes y otras partes del sistema de información. Los directivos tienen el papel de
supervisión en el desarrollo de las bases de datos y de los sistemas de información.
Los administradores de base de datos (ABD) ayudan tanto a los profesionales en sistemas de información
como a los usuarios funcionales. Los administradores de base de datos tienen una amplia variedad de
responsabilidades técnicas y no técnicas (Tabla 3.1). Las habilidades técnicas están más orientadas a los
detalles; las no técnicas están más orientadas a las personas. La principal responsabilidad técnica es diseñar
la base de datos; del lado no técnico, el tiempo del administrador de base de datos se divide entre varias
actividades. Los administradores de base de datos también pueden tener responsabilidades en la planeación
y en la evaluación del SGBD.
La administración de recursos de información es una respuesta al reto de utilizar de forma efectiva la tecnología
de la información. El objetivo de la administración de recursos de información es utilizar la tecnología de
la información como una herramienta de procesamiento, distribución e integración a lo largo de una
organización.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Técnicas No Técnicas
Diseño de esquemas conceptuales
Diseño de esquemas internos Implementar los estándares de la base de datos
Monitoreo del desempeño de la base de datos Crear los materiales de entrenamiento
Seleccionar y evaluar el software de base de datos Promover los beneficios de las base de datos
Diseñar las bases de datos cliente-servidor
Atender consultas de los usuarios
Solucionar los problemas de las bases de datos
Tabla 3.1 Responsabilidades del administrador de base de datos.
La administración de recursos de información tiene muchas semejanzas con la administración de recursos

físicos, como el inventario. La administración de inventarios implica actividades como la salvaguarda del
inventario para evitar su robo o deterioro, el almacenamiento para un uso eficiente, la selección de proveedores,
el manejo de mermas, la coordinación del movimiento y la reducción de costos. La administración de recursos
de información incluye actividades similares: planeación y adquisición de datos, protección de los datos de
acceso no autorizados, aseguramiento de la confiabilidad, coordinación del flujo entre sistemas de información
y eliminación de duplicados.
Como parte del control de recursos de información han surgido nuevas responsabilidades administrativas. El
administrador de datos es una posición gerencial con muchas de estas responsabilidades, siendo la principal,
la planeación del desarrollo de nuevas bases de datos. El administrador de datos conserva una arquitectura
corporativa que describe las bases de datos existentes y la nueva; también evalúa las nuevas tecnologías de
la información y define los estándares para administrar las bases de datos.
El administrador de datos, generalmente, tiene responsabilidades más amplias que el administrador de base
de datos. El papel principal del primero está en la planeación, mientras que el segundo tiene un rol más técnico,
enfocado a bases de datos individuales y SGBD. El administrador de datos también revisa las fuentes de
información desde un contexto más amplio y considera todo tipo de datos, digitales y no digitales. Muchas
organizaciones están haciendo un gran esfuerzo para digitalizar los datos no tradicionales como videos,
materiales de entrenamiento, imágenes y correspondencia. El administrador de datos desarrolla planes a
largo plazo para los datos no tradicionales, mientras que el administrador de base de datos implementa estos
planes usando la tecnología de base de datos apropiada.
Dado el amplio rango de responsabilidades, el administrador de datos normalmente tiene una posición superior
en el organigrama. La figura 3.2 ilustra dos posibles ubicaciones de los administradores de datos y los
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
administradores de base de datos. En una organización pequeña se pueden combinar ambos roles en la
administración de sistemas.
Director de
sistemas
Desarrollo de Administrador de
Soporte técnico Operaciones
aplicaciones datos
Administrador de
base de datos
a) Administrador de datos por debajo del director de sistemas
Administrador de
Director de sistemas
datos
Desarrollo de Administrador de
Soporte técnico Operaciones
aplicaciones base de datos
b) Administrador de datos paralelo al director de sistemas
Figura 3.2 Ubicación en el organigrama de los administradores de datos y de base de datos.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
3.1.3 Responsabilidades de los Administradores de Datos (AD) y los Administradores de

Bases de Datos (ABD).
Como parte del control de recursos de información, han surgido nuevas responsabilidades para la
administración. El administrador de datos (AD) es un puesto de gerencia alta o media con amplias
responsabilidades en cuanto a la administración de los recursos de información. El administrador de base
de datos (ABD) es una función de apoyo con responsabilidades relacionadas con las bases de datos
individuales y los SGBD. La Tabla 3.2 compara las responsabilidades de los administradores de datos y los
administradores de base de datos.
Administrador de datos (AD) Administrador de base de datos (ABD)

Desarrolla el conocimiento detallado sobre los
SGBD individuales.
Realizar consultas sobre el desarrollo de

aplicaciones.
Desarrolla un modelo empresarial de datos.
Lleva a cabo el modelado de datos y el diseño
Establece estándares y políticas entre las bases de lógico de base de datos.
datos con respecto a los nombre, la capacidad para
compartir datos y la propiedad de los datos. Pone en práctica los estándares de administración
de datos.
Negocia los términos contractuales con los
distribuidores de tecnología de la información. Vigila el desempeño de las bases de datos.
Desarrolla planes a largo plazo para la tecnología de Lleva a cabo la evaluación técnica de los SGBD.
la información.
Crea sentencias de seguridad, integridad y
procesamiento de reglas.
Desarrolla estándares y políticas relacionadas con

base de datos individuales y SGBD.
Tabla 3.2 Responsabilidades de los administradores de datos y los administradores de base de datos.
El administrador de datos ve el recurso de la información en un contexto más amplio que el administrador de

base de datos. El primero considera todo tipo de datos, sin importar si están almacenados en base de datos
de relación, archivos, páginas web o fuentes externas. Por lo general, el administrador de base de datos sólo
considera la información almacenada en bases de datos.
Una de las responsabilidades más importantes del administrador de datos es el desarrollo de un modelo de
datos empresariales. Este proporciona un patrón integrado de todas las bases de datos de una organización.
Debido a su alcance, un modelo de datos empresariales es menos detallado que las bases de datos
individuales que comprende. Este modelo se concentra en los temas principales de las base de datos
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
operativas, en lugar de hacer lo en los detalles. Un modelo de datos empresariales se puede desarrollar para
la planeación de los datos (qué bases de datos desarrollar) o el apoyo a las decisiones (cómo integrar y resumir
las bases de datos existentes). Por lo general, el administrador de datos participa en ambos esfuerzos.
Las grandes organizaciones pueden ofrecer una gran cantidad de especialización en la administración de datos
y de base de datos. Para la administración de datos, la especialización puede ser por tarea y entorno. En
cuanto a las tareas, los administradores de datos se pueden especializar en la planeación en lugar del
establecimiento de políticas. En cuanto al entorno, se especializan en entornos como el apoyo a las
decisiones, el procesamiento de transacciones y los datos no tradicionales, como imágenes, texto y video.
Para la administración de base de datos, la especialización puede ocurrir por SGBD, tarea y entorno. Debido
a la dificultad para aprender un SGBD, por lo regular los SGBD se especializan en un producto o en unos
cuantos. La especialización por tareas casi siempre se divide entre el procesamiento de transacciones y
los data warehouses.
En las pequeñas organizaciones, la frontera entre la administración de datos y de base de datos no es muy
estricta. Es probable que no existan puestos separados para administradores de datos y de base de datos,
sino que la misma persona cubra las funciones de ambos. Conforme las organizaciones aumentan de tamaño,
la especialización casi siempre evoluciona hasta que se crean puestos separados.
Para cumplir con las responsabilidades mencionadas, los administradores de base de datos utilizan diversas
herramientas adicionales para seguridad, integridad y acceso a diccionarios de datos, además de analizar el
manejo de procedimientos almacenados y disparadores.
3.2 CREACIÓN DE USUARIOS: el ABD y la Seguridad.
La seguridad comprende la protección de una base de datos del acceso no autorizado y de la destrucción
maliciosa. Debido al valor de la información en las bases de datos corporativas, existe una gran motivación
para los usuarios no autorizados que tratan de obtener acceso ilegal a ellas. Los competidores se sienten
atraídos por el acceso a información delicada sobre los planes de desarrollo de los productos, las iniciativas
para ahorro en costos y los perfiles de los clientes. Los criminales pretenden hurtar resultados financieros no
anunciados, transacciones empresariales e información delicada sobre los clientes, como números de tarjeta
de crédito. Los inadaptados sociales y terroristas pueden causar estragos con la destrucción intencional de
los registros de las bases de datos.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Con el uso cada vez más frecuente del World Wide Web para realizar negociones, competidores, criminales e
inadaptados sociales tienen más oportunidades de poner en riesgo la seguridad de la base de datos.
La seguridad es un amplio tema que comprende muchas disciplinas; existen aspectos legales y éticos
relacionados con quién tiene acceso a los datos y cuándo se pueden revelar. Hay controles de red, de
hardware, de sistema operativo y físicos que aumentan los controles de ofrecen los SGBD. Además, existen
problemas operativos relacionados con contraseñas, dispositivos de autenticación y privacidad. No nos
ocupamos de estos problemas porque se encuentran más allá del alcance de los SGBD y especialistas en
base de datos.
Para controlar el acceso, los SGBD ofrecen soporte para la creación y almacenamiento de reglas de
autorización, así como para su aplicación cuando los usuarios acceden a una base de datos. La siguiente
figura 3.3 ilustra la interacción de estos elementos. Los administradores de base de datos crean reglas de
autorización que definen quién tiene acceso a qué partes de una base de datos para realizar qué operaciones.
La aplicación de las reglas de autorización comprenden la autenticación del usuario y la garantía de que
las consultas de acceso no van a violar las reglas de autorización (recuperaciones y modificaciones a la
base de datos). La autenticación ocurre cuando un usuario se conecta por primera vez a un SGBD. Es preciso
revisar las reglas de autorización para cada solicitud de acceso.
Reglas
de autorización
Sistema de Seguridad
Autenticación
de Base de Datos
consultas de acceso
Diccionario de datos
Figura 3.3 Sistema de seguridad de base de datos.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
El planteamiento más común para las reglas de autorización se conoce como Control de Acceso
Discrecional; en éste, a los usuarios se le asignan derechos o privilegios de acceso a secciones específicas
de una base de datos. Para un control preciso, lo privilegios se especifican para las vista en lugar de las tablas
o los campos. Es posible dar a los usuarios la habilidad de leer, actualizar, insertar y eliminar partes específicas
de una base de datos.
Para simplificar el mantenimiento de las reglas de autorización, es posible asignar privilegios a los grupos o
funciones, en lugar de a los usuarios individuales. Como las funciones son más estables que los usuarios
individuales, las reglas de autorización que hacen referencia a las funciones requieren menos mantenimiento
que las reglas que hacen referencia a usuarios individuales. A los usuarios se les asignan funciones y una
contraseña. Durante el proceso de registro a la base de datos, el sistema de seguridad autentica a los usuarios
e indica qué funciones pertenecen.
Los Controles de Acceso Obligatorio son menos flexibles que los controles de acceso discrecionales. En
los primeros, a cada objeto se le asigna un nivel de clasificación y a cada usuario se le da un nivel de
autorización. Un usuario puede tener acceso a un objeto si su nivel de autorización ofrece acceso al nivel de
clasificación del objeto. Los niveles de autorización y clasificación típicos son confidencial, secreto y súper
secreto. Los planteamientos de control de acceso obligatorio se aplican sobre todo a beses de datos muy
delicadas y estáticas relacionadas con la defensa nacional y la recopilación de inteligencia. En vista de la
flexibilidad limitada de los controles obligatorios de acceso, sólo unos cuantos SGBD ofrecen soporte para
ellos. Sin embargo, los SGBD que se utilizan en la defensa nacional y la recopilación de información deben
ofrecer soporte para los controles obligatorios.
Además de estos controles de acceso, los SGBD ofrecen soporte para la encriptación de base de datos. La
encriptación comprende la codificación de los datos para ocultar su significado. Un algoritmo de encriptación
cambia los datos originales (conocidos como texto plano o plaintext). Para descifrarlos, el usuario proporciona
una llave de codificación que le permite restaurar los datos codificados (conocidos como ciphertext) al formato
original (texto plano). Dos de los algoritmos de encriptación más populares son el estándar de encriptación de
datos (Data Encryption Standard) y el algoritmo de encriptación con llaves públicas (Public-Key Encryption).
Como el estándar de encriptación de datos se puede romper utilizando el poder de la computación masiva, el
algoritmo de encriptación con llaves públicas se ha convertido en el preferido.
Algo que no debe perderse de vista es que la seguridad de las bases de datos se implementa mejor si sólo es
una parte de un plan más amplio para controlar la seguridad. Este plan debe comenzar con medidas físicas
para proteger el edificio, con precauciones especiales para las instalaciones de cómputo. El diseño de un
edificio seguro en su planta física esta claramente fuera del dominio del diseñador de la base de datos.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Es frecuente que éstas comiencen en la entrada principal, donde todos los empleados deben ser identificados
visualmente por guardias, o con el uso de gafetes, huellas digitales, firmas u otros mecanismos. Para ingresar
a las instalaciones de cómputo debe requerirse una identificación adicional. Las medidas físicas de seguridad
deben ampliarse para que cubran cualquier ubicación en la que datos fuera de línea, como los respaldos,
también estén almacenados en forma segura.
Cómo la seguridad física de las estaciones de trabajo puede ser difícil de implementar, los controles de la
seguridad de aquéllas requieren la autentificación de los usuarios. Autentificación significa la verificación de la
identidad del usuario (hacer una comprobación para garantizar que el usuario real es quien dice ser). Por lo
general se implantan al nivel de sistema operativo. Cuando el usuario se registra, él o ella ingresa una ID de
usuario, cuya validez se revisa. El perfil normalmente incluye una clave (password) que se supone sólo conoce
el usuario. Las claves deben conservarse en secreto y cambiadas con frecuencia. Una precaución elemental
de seguridad es que el sistema requiera que las claves se cambien cada mes. Es obvio que el sistema nunca
debe desplegar las claves al registrarse, y los perfiles almacenados deben mantenerse seguros, tal vez en
forma encriptada. Aunque las claves son el método de autentificación que se usa con más amplitud, no son
muy seguras, ya que los usuarios en ocasiones las escriben, escogen palabras que son fáciles de adivinar o
las comparten con otros usuarios. En ciertas organizaciones, los usuarios deben insertar tarjetas o llaves
cuando se registran. En otras, se examina la voz huellas digitales, retina, u otras características físicas del
usuario. Algunas utilizan un procedimiento de autentificación más allá de una sola clave. Un procedimiento
puede consistir en responder una serie de preguntas y requerir de más tiempo y ser más difícil de reproducir
que una clave. Aunque la autentificación puede hacerse sólo a nivel del sistema operativo, es posible que se
pida otra vez al nivel de la base de datos. Como mínimo, debe pedirse al usuario que proporcione una clave
adicional para acceder a la base de datos.
3.2.1 Autorización y Control del Acceso.
Además de la autentificación, la mayor parte de los sistemas de administración de base de datos para
multiusuarios tiene sus propios subsistemas de seguridad, los cuales proveen la autorización de usuario,
método por el que se asigna a los usuarios derechos para usar objetos de la base de datos. La mayoría de
los sistemas multiusuarios tiene un lenguaje de autorización estándar para asegurar privilegios a los usuarios.
El ABD usa el lenguaje de autorización para especificar los derechos del usuario por medio de reglas de
autorización, que son enunciados que especifican cuáles usuarios tienen acceso a cuál información, y cuáles
operaciones les está permitido utilizar sobre qué datos. El mecanismo de autorización está diseñado para
proteger la base de datos al impedir a las personas la lectura, actualización o eliminación no autorizada del
contenido de la base de datos. Estas restricciones se agregan a los mecanismos de seguridad que provee el
sistema operativo.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Sin embargo, en un número sorprendentemente grande de casos, los subsistemas de seguridad de la base de
datos constituyen un recurso corporativo valioso, e incluir los mecanismos de seguridad disponibles como factor
importante en la evaluación alternativa de sistemas de administración de base de datos, así como desarrollar
políticas de seguridad efectivas que utilicen los controles de que dispone el sistema elegido.
Ahora bien, el control del acceso es el medio por el que se implementan las autorizaciones. Controlar el acceso
significa asegurarse de que a los datos u otros recursos sólo se accede en las formas autorizadas.
Al planear el acceso, el ABD puede usar una matriz de control del acceso a la base de datos, como se ilustra
en la siguiente tabla 3.3.
OBJECT
Student WrapUp Faculty Enroll
SUBJECT StuView1 ...
Table Procedure Table Table
User U101 read, read execute read ...

update
User U102 read ...
read, insert,
Role
read read update, ...
Advisor
delete
... ... ... ... ... ... ...
Tabla 3.3 Matriz de Control del Acceso.
Los encabezados de las columnas representan objetos de la base de datos, que pueden ser los nombres de
las tablas, vistas, ítems de datos, objetos, módulos u otras categorías, en función del modelo de la base de
datos y sistema de administración que se utilice. Las etiquetas de las filas representan individuos, roles, grupos
de usuarios o aplicaciones.
El contenido de las celdas especifica el tipo de acceso permitido. Los valores de las entradas también
dependen del sistema particular que se utilice, pero la elección por lo general incluye READ, INSERT, UPDATE,
DELETE y sus combinaciones. Una vez que la matriz de control de acceso está completa, el ABD debe usar
el lenguaje de autorización apropiado para implementarla.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Por supuesto, el ABD le está permitido crear y cambiar la estructura de la base de datos y usar el lenguaje de
autorización para garantizar o revocar el acceso a otros. Algunos sistemas permiten que el ABD delegue parte
de su poder de autorización, en cuyo caso, ciertos usuarios tiene permiso de modificar las estructuras
existentes de la base de datos o crear estructuras nuevas y actualizar el estado de los datos.
En un ambiente multiusuario, tales cambios tienen consecuencias para los demás usuarios. Como el ABD es
con frecuencia el único que tiene un punto de vista amplio de las necesidades de todos los usuarios, es
frecuente que no sea conveniente dar esa clase de autorización. En ocasiones, el ABD da a ciertos el poder
de autorizar a otros la ejecución de operaciones sobre la base de datos. Sin embargo, tener muchos de tales
“autorizadores” es peligroso en extremo, pues los autorizadores generan a otros que también autorizan, lo que
lleva a que la situación se salga de control muy rápido y que el ABD tenga dificultades para revocar las
autorizaciones.
3.2.2 La Seguridad - Creación de Usuarios: Según el SGBD.
Oracle proporciona un sistema amplio de seguridad que va mucho más allá de los comandos del lenguaje de
autorización de SQL, hay muchas formas distintas de estructurar y administrar la seguridad de una base de
datos en Oracle. Lo normal es que el ABD maneje el proceso de garantizar privilegios a los usuarios. Una
forma de hacer esto es por medio de SQL*Plus. El ABD escribe el comando CREATE USER que tiene esta
forma:
CREATE USER nombre del usuario IDENTIFIED BY clave;
Por ejemplo: CREATE USER U999 IDENTIFIED BY SESAME;
Sin embargo, este comando no concede ningún privilegio al usuario, por lo que el U999 no podrá abrir una
sesión a menos que el ABD también escriba lo siguiente:
GRANT CREATE SESSION TO U999;
Para probar esta cuenta, el ABD puede conectarse con el uso del nuevo nombre, si escribe, por ejemplo:
CONNECT U999/SESAME@connectstring;
El administrador conoce @connectstring, que se necesita sólo si Oracle está instalado en red. Es costumbre
pedir que el usuario cambie su clave la primera vez que se registre en la realidad. Esto lo hace el ABD con el
siguiente comando:
ALTER USER nombre del usuario
PASSWORD EXPIRE;
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Cuando el usuario trate de conectarse, recibirá un mensaje que diga que su clave ha expirado y lo invitará a
que establezca una nueva antes de conectarse. Una vez conectado, el usuario también puede cambiar su
clave en cualquier momento con la escritura de los comandos SQL*Plus siguiente:
ALTER USER nombre del usuario

IDENTIFIED BY nueva clave;
Aunque el usuario se conectará, no podrá acceder a ningún dato porque el único privilegio que tiene es el de
abrir una sesión. Para hacer uso de las funcionalidades de Oracle, el usuario necesita que le den privilegios
adicionales, que pueden ser privilegios de sistema o de objeto.
Se proporcionan los siguientes links de internet para observar cómo se realiza la creación y seguridad de usuarios en los
siguientes SGBD.
SQL Server 2019:
https://docs.microsoft.com/es-es/sql/t-sql/statements/create-user-transact-sql?view=sql-server-ver15
https://www.youtube.com/watch?v=Xrbl6Xgmi-Q
PostgresSQL:
https://www.todopostgresql.com/crear-usuarios-en-postgresql/
MySQL Workbench:
https://www.youtube.com/watch?v=46PKYHXpxS4
3.3 PRIVILEGIOS A USUARIOS: Oracle, SQL.
Oracle.
Al cerrar el punto anterior se mencionó que en Oracle contempla privilegios del tipo Objeto y de Sistema,
que a continuación se describen.
3.3.1 Privilegios de Objeto.
En Oracle, un privilegio de objeto es el derecho a ejecutar un comando del LMD sobre una tabla, vista,
procedimiento, función, secuencia o paquete. El creador de un esquema tiene automáticamente todos los
privilegios de objeto sobre todos los objetos que haya en el esquema, y puede garantizar los mismos privilegios
de objeto a otros usuarios. Para las tablas, los privilegios incluyen SELECT, INSERT, UPDATE, DELETE y
REFERENCES, ALTER (el derecho de usar el comando ALTER TABLE) e INDEX (derecho de usar el
comando CREATE INDEX). Para vistas actualizables, los privilegios son SELECT, INSERT, UPDATE y
DELETE.
La sintaxis para éstos es la misa que el de estándar del lenguaje de autorización SQL, por ejemplo, el ABD
pude conceder al U999 privilegios amplios sobre la tabla Student con escritura de lo siguiente:
GRANT ALL PRIVILEGES ON Student TO U999 WITH GRANT OPTION;

Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Si hay almacenado un procedimiento llamado WrapUp, el ABD puede dar permiso a U999 para correrlo con la
escritura de este comando:
GRANT EXECUTE ON WrapUp TO U999;
3.3.2 Privilegios de Sistema.
En Oracle, un privilegio de sistema incluye el derecho a ejecutar acciones con el uso de comandos LDD
sobre datos, esquemas, espacios para tablas u otros recursos de la base de datos Oracle, así como el derecho
de crear cuentas de usuarios. Hay alrededor de 140 posibles diferentes privilegios de sistema. La lista de ellos
se obtiene con el siguiente comando de SQL:
SELECT name
FROM SYSTEM_PRIVILEGE_MAP;
Los privilegios de sistema se dan a través de SQL*Plus con el uso del comando GRANT, en esta forma:
GRANT privilegio de sistema

TO nombre de usuario
[WITH ADMIN OPTION];
Por ejemplo, se permitiría al U999 que creara tablas si se escribe:
GRANT CREATE TABLE TO U999 WITH ADMIN OPTION;
Adicionalmente, los privilegios que son privilegios de objeto en tablas únicas pueden extenderse para
convertirlos en privilegios de sistema que se extiendan a cualquier tabla, con el uso de la palabra clave ANY,
así:
GRANT SELECT ANY TABLE TO U999;
La cláusula WITH ADMIN OPTION permite al usuario pasar el privilegio a otros.
Oracle no depende del sistema operativo para la creación de usuarios, proporciona la sentencia CREATE
USER. De igual manera ofrece funciones predefinidas para usuarios con altos privilegios que incluyen la
función CONNECT (conectar) para crear tablas en un esquema, la función RESOURCE para crear tablas y
objetos de aplicaciones como procedimientos almacenados, y la función DBA para administrar base de datos.
Oracle distingue entre los privilegios del sistema (independientes al objeto) y los privilegios del objeto; por lo
regular, el hecho de otorgar privilegios de objetos está reservado para funciones altamente seguras debido al
largo alcance de los privilegios del sistema, como muestra la tabla 3.4. Los privilegios de objeto de Oracle son
similares a los de SQL:2003, sólo que Oracle proporciona más objetos que SQL:2003, como se ilustra en la
tabla 3.5.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
La mayoría de los SMBD permiten restricciones de autorización por objetos de aplicaciones, como formularios
y reportes, además de los objetos de bases de datos permitidos en la sentencia GRANT. Estas limitaciones
adicionales de seguridad casi siempre se especifican en las interfaces propietarias o en las herramientas de
desarrollo de aplicaciones, en lugar de SQL.
Privilegio de Sistema Descripción
Crea objetos tipo X enel propio esquema; CREATE ANY permite

CREATE X, CREATE ANY X
la creación de objetos en otros esquemas1
Alter a objetos tipo X en el propio esquema; ALTER ANY

ALTER X, ALTER ANY X
permite alterar objetos en otros esquemas
INSERTE ANY, DELETE ANY, Inserta, elimina, actualiza y selecciona de una tabla en
UPDATE ANY, SELECT ANY cualquier esquema
RETIRA objetos tipo X en el propio esquema; DROP ANY

DROP X, DROP ANY X
permite retirar objetos en otros esquemas
ALTER SYSTEM, ALTER Emite comandos ALTER SYSTEM, comandos ALTERDATABASE y

DATABASE, ALTER SESSION comandos ALTER SESSION
ANALYZE ANY Analiza cualquier tabla, índice o grupo
Tabla 3.4 Descripción de los privilegios de sistema comunes en Oracle.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Objeto
Procedimiento, función paquete, Vista

Privilegio Tabla Vista Secuencia2
biblioteca, operador, tipo de índice materializada3
ALTER X X
DELETE X X X
EXECUTE X
INDEX X
INSERT X X X
REFERENCES X X
SELECT X X X X
UPDATE X X X
Tabla 3.5 Diagramación entre los privilegios y objetos comunes de Oracle.
1 Un esquema es un grupo de tablas relacionadas y otros objetos de Oracle que se manejan como una unidad.
2 Una secuencia es un grupo de valores que mantiene Oracle. Por lo regular, las secuencias se utilizan para llaves primarias generadas
por el sistema.
3 Una vista materializada se guarda en lugar de derivarse. Las vistas materializadas son útiles en los data warehouses.
SQL.
3.3.3 Autorización.
Se pueden asignar a los usuarios varios tipos de autorización (lectura, inserción, actualización, borrado) para
diferentes partes de la base de datos. Cada uno de estos tipos de autorización se denomina privilegio. Se
puede conceder a cada usuario todos estos tipos de privilegios, ninguno de ellos o una combinación de los
mismos sobre partes concretas de la base de datos, como puede ser una relación o una vista.
La norma de SQL incluye los privilegios SELECT, INSERT, UPDATE y DELETE, así como también el de crear,
borrar o modificar relaciones y ejecutar procedimientos. SQL especifica que sólo el propietario del esquema
puede llevar a cabo modificaciones del mismo; por lo tanto, la creación o eliminación de relaciones, la adición
o descarte de atributos de las relaciones y la adición o descarte de índices, sólo puede ejecutarlas el propietario
del esquema.
SQL también incluye un privilegio REFERENCES que permite que los usuarios declaren claves externas al
crear las relaciones. Inicialmente, puede parecer que no hay ninguna razón para impedir que los usuarios
creen claves externas que hagan referencia a otras relaciones, sin embargo, recuérdese que las restricciones
de clave externa restringen las operaciones de borrado y de actualización de la relación a la que se hace
referencia. Supóngase que U1 crea una clave externa en la relación r que hace referencia al atributo
nombre_sucursal de la relación sucursal y luego inserta una tupla en r correspondiente a la sucursal de
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Navacerrada. Ya no es posible borrar la sucursal de Navacerrada de la relación sucursal sin modificar

también la relación r. Por tanto, la definición de una clave externa por U1 restringe la actividad futura de otros
usuarios; en consecuencia, el privilegio REFERENCES es necesario.
El privilegio REFERENCES también es necesario para crear restricciones CHECK sobre una relación, si alguna
restricción tiene una subconsulta que hace referencia a la relación involucrada.
SQL define el privilegio EXECUTE; este privilegio autoriza a los usuarios a ejecutar funciones o procedimientos
(tema 5), por lo que, sólo los usuarios que tienen el privilegio EXECUTE sobre la f() pueden llamarla (bien
directamente, bien desde una consulta de SQL).
SQL también incluye el privilegio USAGE, que autoriza a los usuarios a emplear el dominio especificado
(recuérdese que los dominios se corresponden con el concepto de tipo de los lenguajes informáticos y pueden
ser definidos por los usuarios).
Privilegio Descripción
SELECT Consulta el objeto; puede especificarse para columnas individuales.
UPDATE Modifica el valor; puede especificarse para columnas individuales.
Agrega una nueva fila; puede especificarse para columnas

INSERT
individuales.
DELETE Elimina una fila; puede especificarse para columnas individuales.
TRIGGER Crea un disparador para unja tabla especifica.
Hace referencia a las columnas de una tabla determinada con

REFERENCES
limitaciones de integridad.
EXECUTE Ejecuta el procedimiento almacenado.
Tabla 3.6 Descripción de los privilegios comunes en SQL:2003.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
La forma de autoridad definitiva es la dada al ABD; este puede autorizar nuevos usuarios, reestructurar la base
de datos, etc. Esta forma de autorización es análoga a la de superusuario u operador de un sistema operativo.
En el SQL estándar, se dan al creador de un esquema todos los privilegios sobre todos los objetos (tablas,
vistas, roles, módulos) pertenecientes al esquema, y pueden otorgar esos privilegios a otros usuarios. Lo
común es que sólo el creador del esquema lo pueda modificar (agregar tablas, columnas, etc.). El enunciado
para dar privilegios tiene la forma siguiente:
GRANT { ALL PRIVILEGES | lista de privilegios }
ON { table-name | nombre de vista }
TO { PUBLIC | lista de usuarios | lista de roles } [ WITH GRANT OPTION ]
Lista de privilegios: SELECT, DELETE, INSERT, UPDATE o REFERENCES (nombre de columnas). Si una
tabla se especifica en la cláusula ON, entonces ALL PRIVILEGES incluye todas estas operaciones. Si una
vista se especifica en la cláusula ON y se construyó en forma tal que sea actualizable, en esa vista pueden
asegurarse los privilegios SELECT, DELETE, INSERT, y UPDATE. Para vistas no actualizables, sólo puede
garantizarse SELECT. El privilegio UPDATE se hace más restrictivo al especificar una lista de columnas en
los paréntesis después de la palabra UPDATE, lo que restringe al usuario a actualizar sólo ciertas columnas,
por ejemplo así:
GRANT UPDATE ON Student(major) TO U101;
El privilegio REFERENCES se aplica a columnas que se usan como claves externas. Este privilegio permite
al usuario hacer referencia a éstas en la creación de restricciones de integridad de claves externas. Por
ejemplo, para permitir a un usuario capaz de actualizar la tabla Enroll que pueda hacer referencia a stuId en
la tabla Student con objeto de comparar sus valores para la tabla Enroll, se escribe:
GRANT REFERENCES (stuId) ON Student TO U101;
La lista del usuario en la cláusula TO puede incluir a uno o varios usuarios. SQL:1999 incluye la capacidad de
crear roles de usuario, que se trata más adelante.
El enunciado de SQL para quitar privilegios tiene la forma siguiente:
REVOKE { ALL PRIVILEGES | lista de privilegios }

ON lista de objetos
FROM { PUBLIC | lista de usuarios | lista de roles }
[ CASCADE | RESTRICT ];
Por ejemplo, para U101, al cual previamente se había garantizado SELECT, INSERT y UPDATE, para Student
con la opción GRANT, podrían retirársele algunos privilegios si se escribiera esto:
REVOKE INSERT ON Student FROM U101;
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Esto revoca la capacidad de U101 tanto para insertar registros en Student como para autorizar a otros a
hacerlo. Puede revocarse sólo la opción GRANT sin revocar INSERT, si se escribe lo siguiente:
REVOKE GRANT OPTION FOR INSERT ON Student FROM U101;
Si un individuo tiene la opción GRANT para cierto privilegio, y si después se revoca éste o la opción, todos los
usuarios que hubieran recibido el privilegio de dicho individuo también verían revocado su privilegio. De esta
manera, las revocaciones actúan en cascada, es decir, verían revocado su privilegio. Si un usuario obtuvo el
mismo privilegio de dos autorizaciones, y a uno de los cuales revocó la autorización, el usuario aún conserva
el privilegio por parte del otro autorizador.
En la siguiente figura 3.4, se presenta un ejemplo donde el ABD revocó la autorización del usuario U1, U21
perdería todos sus privilegios, pero U22 conservaría los que hubiera recibido de U2. Como U22 tiene la opción
GRANT, el usuario U21 podría volver a obtener privilegios de U22. De esta manera, los usuarios poco
escrupulosos podrían estar en posibilidad de conspirar para conservar privilegios a pesar de los intentos del
ABD para anularlos. Por esta razón, el ABD debe ser muy cuidadoso respecto a pasar la opción GRANT a
otras personas. Si se especifica la opción RESTRICT, el sistema comprueba si hay algunas revocaciones en
cascada, y si existen devuelve un mensaje de error sin ejecutar el enunciado de revocación. El valor de
antemano es CASCADE. Cuando se anula un privilegio, el grafo de autorización se modifica con la eliminación
del (los) nodo(s) que perdió (perdieron) sus privilegios.
Figura 3.4 Grafo de autorización.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
3.4 ROLES.
Un rol puede considerarse como un conjunto de operaciones que deben ser ejecutadas por un individuo o
grupo de individuos como parte de un trabajo. Por ejemplo, en una universidad, los asesores tal vez necesiten
leer los expedientes de estudiantes seleccionados, por lo que debería haber un rol Advisor (tutor) que lo
permitiera. En función de las políticas de la universidad, el rol Advisor también incluye el privilegio de insertar
registros de inscripción para los estudiantes en el momento de darse de alta. Se permite a los estudiantes
ejecutar la operación SELECT pero no UPDATE en sus datos personales, por lo que tiene que haber un rol
Student que permita ese acceso. Una vez que el ABD ha identificado un rol, garantiza para éste un conjunto
de privilegios y luego le asigna las cuentas de usuario. Algunas de dichas cuentas tienen varios roles. Si se
especifica PUBLIC en la cláusula TO, se da a todos los usuarios los privilegios especificados en el enunciado
GRANT. La cláusula opcional WITH GRANT OPTION permite a los usuarios recientemente autorizados
otorgar los mismos privilegios a otros. Por ejemplo, se podría escribir:
GRANT SELECT, INSERT, UPDATE ON Student TO U101, U102, U103 WITH GRANT OPTION;
Entonces, se permitiría a los usuarios U101, U102 y U103 escribir enunciados SQL, SELECT, INSERT y
UPDATE para la tabla Student y pasar el permiso a otros usuarios. Debido a la capacidad que la opción GRANT
da a los usuarios para autorizar a otros, el sistema debe dar seguimiento de las autorizaciones por medio de
un diagrama de garantías, también llamado grafo de autorización (figura 3.4); como se vio en el tema
pasado.
En la base de datos se crea un conjunto de roles. Las autorizaciones se pueden conceder a los roles
exactamente igual que se conceden a los usuarios. Se concede un conjunto de roles (que puede estar vacío)
que está autorizado a desempeñar a cada usuario de la base de datos. El uso de los roles tiene la ventaja de
exigir a los usuarios que se conecten con su propio identificador de usuario. Cualquier autorización que se
pueda conceder a los usuarios se puede conceder a los roles. Los roles se conceden a los usuarios igual que
las autorizaciones. Y, como otras autorizaciones, también se les puede conceder a los usuarios autorización
para conceder un rol concreto a otros. Téngase en cuenta que pude haber cadenas de roles donde se hereden
todos los privilegios concedidos.
Las acciones ejecutadas por las sesiones tienen todos los privilegios concedidos directamente usuario que las
ha abierto, así como todos los privilegios concedidos a los roles que se hayan concedido (directa o
indirectamente, a través de otros roles) a ese usuario. Además del concepto de usuario (actual) de la sesión,
SQL también tiene el concepto de rol actual asociado a la sesión. De manera predeterminada, el rol actual
asociado con un sesión es nulo (excepto en algunos casos especiales). El rol actual asociado con la sesión
se puede definir ejecutando SET ROLE nombre_rol. El rol especificado deber haberse concedido al usuario, o
la instrucción SET ROLE fallará.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.
ISC
Cuando se conceden privilegios se tratan de manera predeterminada como si los hubiera concedido el usuario
actual, es decir, el concedente es el usuario actual. Para conceder privilegios con el concedente definido como
rol actual asociado con una sesión se pude añadir la cláusula GRANTED BY CURRENT_ROLE a la instrucción
GRANT, siempre y cuando el rol actual no sea nulo.
Continuando con el ejemplo de la universidad, para crear un rol se escribe un enunciado como el que sigue:
CREATE ROLE AdvisorRole;

CREATE ROLE FacultyRole;
Después se garantizan privilegios al rol del mismo modo que se hace con los individuos, al escribir enunciados
como los siguientes:
GRANT SELECT ON Student TO AdvisorRole;

GRANT UPDATE ON Enroll TO AdvisorRole;
GRANT SELECT ON Enroll TO FacultyRole;
Para asignar un rol a un usuario se escribe un enunciado así:
GRANT AdvisorRole TO U999;
Incluso se puede asignar un rol a otro rol si se escribe, por ejemplo:
GRANT FacultyRole TO AdvisorRole;
Esto da un medio de heredar privilegios a través de roles.
Clave: SCA-1025
Grupo: 5504 B / 13:00 – 14:00 hrs.
Grupo: 5504 C / 16:00 – 17:00 hrs.

TEMA III - Control de Acceso - Ago-Dic 2021

Cargado por

Copyright:

Formatos disponibles

TEMA III - Control de Acceso - Ago-Dic 2021

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TEMA III - Control de Acceso - Ago-Dic 2021

Cargado por

Copyright:

Formatos disponibles

ISC

Apuntes de TBD Instituto Tecnológico de Ciudad Madero

ACTIVIDAD INTRODUCCIÓN. Acceder a las siguientes dirección de internet e intercambiar ideas

a) Seguridad de datos: En qué consiste y qué es importante en tu empresa

b) La estrategia de seguridad en las bases de datos

3.1 TIPOS DE USUARIOS.

• Diseñador de base de datos: es el encargado de estructurar la arquitectura para representar y

3. Diseñadores e implementadores del SGBD: se encarga de diseñar e implementar los módulos e

3.1.1 Administrador de Base de Datos (ABD) y la seguridad en base de datos.

3.1.2 Impactos organizacionales de la tecnología de Base de datos.

Figura 3.1 Clasificación de roles.

Tabla 3.1 Responsabilidades del administrador de base de datos.

La administración de recursos de información tiene muchas semejanzas con la administración de recursos

a) Administrador de datos por debajo del director de sistemas

b) Administrador de datos paralelo al director de sistemas

Figura 3.2 Ubicación en el organigrama de los administradores de datos y de base de datos.

3.1.3 Responsabilidades de los Administradores de Datos (AD) y los Administradores de

Administrador de datos (AD) Administrador de base de datos (ABD)

Realizar consultas sobre el desarrollo de

Desarrolla estándares y políticas relacionadas con

El administrador de datos ve el recurso de la información en un contexto más amplio que el administrador de

3.2 CREACIÓN DE USUARIOS: el ABD y la Seguridad.

Figura 3.3 Sistema de seguridad de base de datos.

3.2.1 Autorización y Control del Acceso.

User U101 read, read execute read ...

User U102 read ...

... ... ... ... ... ... ...

Tabla 3.3 Matriz de Control del Acceso.

3.2.2 La Seguridad - Creación de Usuarios: Según el SGBD.

Por ejemplo: CREATE USER U999 IDENTIFIED BY SESAME;

ALTER USER nombre del usuario

3.3 PRIVILEGIOS A USUARIOS: Oracle, SQL.

3.3.1 Privilegios de Objeto.

GRANT ALL PRIVILEGES ON Student TO U999 WITH GRANT OPTION;

GRANT EXECUTE ON WrapUp TO U999;

3.3.2 Privilegios de Sistema.

GRANT privilegio de sistema

GRANT CREATE TABLE TO U999 WITH ADMIN OPTION;

La cláusula WITH ADMIN OPTION permite al usuario pasar el privilegio a otros.

Privilegio de Sistema Descripción

Crea objetos tipo X enel propio esquema; CREATE ANY permite

Alter a objetos tipo X en el propio esquema; ALTER ANY

RETIRA objetos tipo X en el propio esquema; DROP ANY

ALTER SYSTEM, ALTER Emite comandos ALTER SYSTEM, comandos ALTERDATABASE y

ANALYZE ANY Analiza cualquier tabla, índice o grupo

Tabla 3.4 Descripción de los privilegios de sistema comunes en Oracle.

Procedimiento, función paquete, Vista

Navacerrada. Ya no es posible borrar la sucursal de Navacerrada de la relación sucursal sin modificar

SELECT Consulta el objeto; puede especificarse para columnas individuales.

UPDATE Modifica el valor; puede especificarse para columnas individuales.

Agrega una nueva fila; puede especificarse para columnas

DELETE Elimina una fila; puede especificarse para columnas individuales.

TRIGGER Crea un disparador para unja tabla especifica.

Hace referencia a las columnas de una tabla determinada con

EXECUTE Ejecuta el procedimiento almacenado.

Tabla 3.6 Descripción de los privilegios comunes en SQL:2003.

GRANT REFERENCES (stuId) ON Student TO U101;

El enunciado de SQL para quitar privilegios tiene la forma siguiente: