Acerca de la aplicación

El contenido del script de esta página es sólo para fines de navegación y no modifica el contenido de ninguna forma.

La aplicación tiene la siguiente finalidad, estructura y convenciones de nomenclatura.

Finalidad de la aplicación

La aplicación está destinada a dos tipos de usuarios en una compañía.

• Usuarios típicos (mánager de empleados)

• administradores de la aplicación

Los usuarios habituales pueden realizar las siguientes tareas:

• Obtener empleados en un departamento determinado

• Obtener el historial de trabajos de un empleado determinado

• Mostrar información general de un empleado determinado (nombre, departamento, puesto, mánager, salario, etc.)

• Cambiar el salario de un empleado determinado

• Cambiar el trabajo de un empleado determinado

Los administradores de aplicaciones pueden realizar las siguientes tareas:

• Cambiar el ID, el cargo o el rango salarial de un puesto existente

• Agregar un nuevo trabajo

• Cambiar el ID, el nombre o el mánager de un departamento existente

• Agregar un nuevo departamento

Estructura de la aplicación

La aplicación utiliza los siguientes objetos y esquemas de esquema.

Objetos de Esquema de la Aplicación

La aplicación se compone de los siguientes objetos de esquema:

• Cuatro tablas que almacenan los siguientes datos:

  • Trabajos

  • Departments

  • Empleados

  • Historial de puestos de empleados

• Cuatro vistas de edición, que abarcan las tablas, lo que permite utilizar la redefinición basada en edición (EBR) para actualizar la aplicación terminada cuando está en uso

• Dos disparadores, que aplican reglas de negocio

• Dos secuencias que generan claves primarias únicas para nuevos departamentos y empleados

• Dos paquetes:

  • employees_pkg, la interfaz de programa de aplicación (API) para usuarios típicos

  • admin_pkg, la API para administradores de aplicaciones

  Los usuarios y administradores de aplicaciones típicos acceden a la aplicación solo a través de sus API. Por lo tanto, solo pueden cambiar los datos llamando a subprogramas de paquetes.

Consulte además:

• "Acerca de Oracle Database" para obtener información sobre los objetos de esquema

• Oracle Database Development Guide para obtener información sobre EBR

Esquemas para la aplicación

Por motivos de seguridad, la aplicación utiliza los siguientes cinco esquemas (o usuarios), cada uno de los cuales solo tiene los privilegios que necesita.

• app_data posee todos los objetos de esquema excepto los paquetes y carga sus tablas con datos de tablas en el esquema de ejemplo HR

  Los desarrolladores que crean los paquetes nunca funcionan en este esquema. Por lo tanto, no pueden modificar ni borrar accidentalmente objetos de esquema de aplicación.

• app_code solo posee el paquete employees_pkg

  Los desarrolladores de employees_pkg trabajan en este esquema.

• app_admin solo es propietario del paquete admin_pkg

  Los desarrolladores de admin_pkg trabajan en este esquema.

• app_user, el usuario de aplicación típico, no posee nada y solo puede ejecutar employees_pkg

  El servidor de aplicaciones de capa media se conecta a la base de datos en el pool de conexiones como app_user. Si este esquema se ve comprometido, por ejemplo, por un bug de inyección SQL, el atacante solo puede ver y cambiar lo que los subprogramas employees_pkg le permiten ver y cambiar. El atacante no puede borrar tablas, escalar privilegios, crear o modificar objetos de esquema ni nada más.

• app_admin_user, un administrador de aplicaciones, no posee nada y solo puede ejecutar admin_pkg y employees_pkg

  El pool de conexiones para este esquema es muy pequeño y solo pueden acceder a él los usuarios con privilegios. Si este esquema se ve comprometido, el atacante solo puede ver y cambiar lo que los subprogramas admin_pkg y employees_pkg le permiten ver y cambiar.

Supongamos que en lugar de app_user y app_admin_user, la aplicación solo tenía un esquema que no poseía nada y podía ejecutar tanto employees_pkg como admin_pkg. El pool de conexiones de este esquema tendría que ser lo suficientemente grande para los usuarios típicos y los administradores de la aplicación. Si hubiera un error de inyección SQL en employees_pkg, un usuario típico que aprovechara ese error podría acceder a admin_pkg.

Supongamos que, en lugar de app_data, app_code y app_admin, la aplicación solo tenía un esquema que era propietario de todos los objetos de esquema, incluidos los paquetes. Los paquetes tendrían entonces todos los privilegios en las tablas, lo que sería innecesario e indeseable.

Por ejemplo, supongamos que tiene una tabla de pista de auditoría, AUDIT_TRAIL. Desea que los desarrolladores de employees_pkg puedan escribir en AUDIT_TRAIL, pero no leerlo ni cambiarlo. Desea que los desarrolladores de admin_pkg puedan leer AUDIT_TRAIL y escribir en él, pero no cambiarlo. Si AUDIT_TRAIL, employees_pkg y admin_pkg pertenecen al mismo esquema, los desarrolladores de los dos paquetes tienen todos los privilegios en AUDIT_TRAIL. Sin embargo, si AUDIT_TRAIL pertenece a app_data, employees_pkg pertenece a app_code y admin_pkg pertenece a app_admin, puede conectarse a la base de datos como app_data y hacer lo siguiente:

GRANT INSERT ON AUDIT_TRAIL TO app_code;
GRANT INSERT, SELECT ON AUDIT_TRAIL TO app_admin;

Consulte además:

• "Acerca de Oracle Database" para obtener información sobre los esquemas

• "Acerca de HR de Esquema de Ejemplo" para obtener información sobre el esquema de ejemplo HR

• "Prácticas de Seguridad Recomendadas"

Reglas de nomenclatura en la aplicación

La aplicación utiliza estas convenciones de nomenclatura.

Elemento	Nombre
Tabla	tabla#
Vista de edición para tabla#	tabla
Disparador en la vista de edición tabla	table_{a|b}evento[_fer] donde: a identifica un disparador AFTER. b identifica un disparador BEFORE. fer identifica un disparador FOR EACH ROW. event identifica el evento que dispara el disparador. Por ejemplo: i para INSERT, iu para INSERT o UPDATE, d para DELETE.
La restricción PRIMARY KEY en tabla#	tabla_pk
Restricción NOT NULL en tabla#.columna	table_column_not_null (nota al pie 1)
Restricción UNIQUE en table#.column	table_column_unique (nota al pie 1)
Restricción CHECK en table#.column	table_column_check (nota al pie 1)
Restricción de referencia en table1#.column a table2#.column	tabla1_to_tabla2_fk (nota al pie 1)
Restricción de referencia en table1#.column1 a table2#.column2	table1_col1totable2_col2_fk (nota al pie 1) (nota al pie 2)
Secuencia para table#	tabla_secuencia
Nombre del parámetro	p_nombre
Nombre de variable local	l_nombre

Nota al pie 1: la tabla, la tabla1 y la tabla2 se abrevian para asignar empleados, departamento para departamentos e historial_trabajo para historial_trabajo.

Nota al pie 2: col1 y col2 son abreviaturas de nombres de columna column1 y column2. El nombre de una restricción no puede tener más de 30 caracteres.