Fundamentos Clave en Bases de Datos: Selección de Motor, Configuración en Oracle y Gestión de Acceso Seguro

¿Qué factores deben considerarse para seleccionar un motor de base de datos para una empresa pequeña con pocos usuarios? Indica cuatro factores:

Al seleccionar un motor de base de datos para una empresa pequeña con pocos usuarios, se deben considerar los siguientes factores:

• Costo: Evaluar si se requieren licencias o si existen opciones de uso gratuito.
• Facilidad de uso y configuración: La simplicidad en la implementación y mantenimiento es crucial.
• Soporte para conexiones concurrentes: Verificar si el sistema es adecuado para pocas conexiones concurrentes, como es el caso de SQLite o Access.
• Capacidad de gestión de datos: Determinar si se necesita una gestión monousuario o multiusuario básico.

Menciona tres factores clave para elegir un sistema gestor de bases de datos (SGBD):

Los factores clave para elegir un SGBD incluyen:

• Cantidad de usuarios y conexiones simultáneas: El número de usuarios que accederán a la base de datos concurrentemente.
• Arquitectura requerida: Definir si la arquitectura será monocapa, cliente/servidor o multicapa.
• Localización de los datos: Decidir si los datos estarán centralizados o distribuidos.

¿Qué tipos de parámetros de configuración inicial se deben definir al crear una base de datos en Oracle? Explica brevemente 4 tipos de parámetros:

Al crear una base de datos en Oracle, es fundamental definir varios parámetros de configuración inicial. Cuatro tipos importantes son:

• Parámetros de memoria: Definen el tamaño de la memoria compartida (SGA) y la caché de búfer de base de datos, entre otros componentes de memoria vitales para el rendimiento.
• Parámetros de red: Configuran aspectos como el número máximo de conexiones permitidas y la configuración de los listeners y clientes para la comunicación con la base de datos.
• Parámetros de seguridad: Establecen políticas para contraseñas (complejidad, expiración), la creación de perfiles de usuario con límites de recursos y las políticas de acceso generales.
• Formato y localización (NLS Parameters): Determinan el idioma para mensajes y ordenación, la moneda, el formato de fechas y números, y otros aspectos culturales y de representación de datos específicos de la región.

Un usuario debe poder consultar datos sensibles, pero sin ver información confidencial de algunas columnas. ¿Qué solución implementarías?

Para esta situación, la solución más adecuada es crear una vista. Esta vista se diseñaría para que seleccione únicamente las columnas no confidenciales de la tabla original, excluyendo aquellas con información sensible. Posteriormente, se otorgaría al usuario el privilegio SELECT exclusivamente sobre esta vista, impidiendo el acceso directo a la tabla subyacente que contiene los datos confidenciales.

¿Cómo garantizarías que los analistas de una empresa tengan acceso únicamente a los datos necesarios para realizar sus funciones sin exponer información sensible?

Para asegurar que los analistas accedan solo a los datos necesarios y no expongan información sensible, implementaría las siguientes medidas de seguridad y control de acceso:

• Diseñar vistas personalizadas: Estas vistas se crearían para cada perfil de analista o tipo de tarea, limitando la información accesible (tanto filas como columnas) estrictamente a lo que requieren para sus funciones. Esto se conoce como el principio de mínimo privilegio.
• Impedir el acceso directo a tablas: Se aseguraría que los analistas no tengan permisos para consultar directamente las tablas originales que contienen datos sensibles o información no relevante para su rol.
• Otorgar privilegios de solo lectura (SELECT) sobre estas vistas, evitando cualquier modificación accidental o intencionada de los datos a través de estas interfaces de acceso controlado.

Explica brevemente y justifica: ¿Por qué es importante crear roles en lugar de asignar privilegios directamente a los usuarios?

Es fundamental crear roles en la gestión de bases de datos en lugar de asignar privilegios directamente a los usuarios por varias razones estratégicas y operativas:

• Simplificación de la gestión de permisos: Los roles agrupan un conjunto de privilegios comunes necesarios para una función o tarea específica (ej. 'AnalistaVentas', 'Contador'). Asignar un rol a un usuario es más sencillo y menos propenso a errores que asignar múltiples privilegios individualmente.
• Eficiencia en la administración: Si es necesario modificar los permisos para un grupo de usuarios (por ejemplo, añadir o revocar un privilegio), solo se necesita modificar el rol, y el cambio se aplicará automáticamente a todos los usuarios que tengan ese rol asignado. Esto ahorra tiempo y esfuerzo.
• Consistencia y estandarización: Asegura que todos los usuarios con la misma función tengan exactamente los mismos permisos, evitando inconsistencias que podrían surgir de la asignación manual y que podrían derivar en brechas de seguridad o problemas de acceso.
• Facilidad en el control de acceso y auditoría: Es más fácil revisar, auditar y documentar los permisos cuando están organizados por roles que cuando están dispersos entre numerosos usuarios individuales. Simplifica la demostración de cumplimiento normativo.
• Reducción de errores administrativos: Minimiza la probabilidad de errores al asignar o revocar permisos, ya que la gestión se centraliza en los roles, disminuyendo la complejidad de la administración de la seguridad.

¿Cómo decidirías qué privilegios otorgar a un usuario que necesita actualizar registros de una base de datos, pero no modificar su estructura?

A un usuario que necesita actualizar registros pero no modificar la estructura de la base de datos, le otorgaría privilegios siguiendo el principio de mínimo privilegio. Específicamente:

• Privilegios de Manipulación de Datos (DML): Se le concederían los permisos UPDATE sobre las tablas o vistas específicas que necesita modificar. Dependiendo de sus responsabilidades exactas, también podría necesitar los privilegios INSERT (para añadir nuevos registros) y/o DELETE (para eliminar registros existentes). Es crucial que estos permisos se concedan únicamente sobre los objetos (tablas/vistas) que el usuario legítimamente necesita manipular para sus tareas.
• Ningún privilegio de Definición de Datos (DDL): Se evitaría explícitamente otorgar permisos que permitan alterar la estructura de la base de datos. Esto incluye comandos como CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX, TRUNCATE TABLE, etc. Estos son permisos estructurales que deben reservarse para administradores de bases de datos o roles con mayor nivel de autorización.

Esta aproximación asegura que el usuario pueda cumplir con sus tareas de actualización de datos sin comprometer la integridad estructural ni la seguridad general de la base de datos.