8.3. CREAR Y GESTIONAR ROLES.

CREAR Y GESTIONAR ROLES.
Administrar la seguridad con privilegios otorgados directamente funciona, pero tiene dos problemas. Primero, puede ser una enorme carga de trabajo: una aplicación con miles de tablas y los usuarios pueden necesitar millones de GRANT. Segundo, si un privilegio ha sido otorgado a un usuario, ese usuario lo tiene en todas las circunstancias: no es posible hacer un privilegio activo solo en ciertas circunstancias. Ambos problemas se resuelven utilizando roles. Un rol es un paquete o conjunto de privilegios de sistemas y de objetos que pueden ser otorgados y revocados como una unidad, y habiendo sido concedidos pueden ser temporalmente activados o desactivados dentro de una sesión.


CREANDO Y OTORGANDO ROLES.

Los roles no son esquemas de objetos: no son propiedad de nadie y así que no pueden ser prefijados con un username. Sin embargo, comparten el mismo namespace como usuarios: no es posible crear un rol con el mismo nombre que un usuario ya existente o un usuario con el mismo nombre de un rol ya existente.

Crear un rol con el comando CREATE ROLE:


CREATE ROLE rolename ;

A continuación otorgue privilegios al Rol con la sintaxis usual, incluyendo WITH ADMIN o WITH GRANT OPTION deseada.

Por ejemplo, suponer que el esquema HR se utiliza como un repositorio de Datos para ser utilizado por tres grupos de personal: Managerial staff tiene acceso completo, Senior Clarical Staff tiene acceso limitado, Junio Clerical staff tiene acceso muy restringido. Primero crear un Rol que podría ser adecuado para Junior Clerk; todo lo que puede hacer es responder a las preguntas de ejecución de consultas:

create role hr_junior;
grant create session to hr_junior;
grant select on hr.regions to hr_junior;
grant select on hr.locations to hr_junior;
grant select on hr.countries to hr_junior;
grant select on hr.departments to hr_junior;
grant select on hr.job_history to hr_junior;
grant select on hr.jobs to hr_junior;
grant select on hr.employees to hr_junior;


Cualquiera que otorga este roll sera capaz para conectarse a la Base de Datos y ejecutar sentencias SELECT contra las tablas de HR. Luego crear un Rol para el senior Clerks, que también puede escribir datos a las tablas EMPLOYEES y JOB_HISTORY:


create role hr_senior;
grant hr_junior to hr_senior with admin option;
grant insert, update, delete on hr.employees to hr_senior;
grant insert, update, delete on hr.job_history to hr_senior;

A este roles primero otorgado el rol HR_JUNIOR (no hay problemas otorgar un rol a otro) con la sintaxis que permitirá a los usuarios senior asignar el rol junior a otros. A continuación se otorgan privilegios DML a solo dos tablas. A continuación crear el Rol Managers, que puede actualizar todas las otras tablas:

create role hr_manager;
grant hr_senior to hr_manager with admin option;
grant all on hr.regions to hr_manager;
grant all on hr.locations to hr_manager;
grant all on hr.countries to hr_manager;
grant all on hr.departments to hr_manager;
grant all on hr.job_history to hr_manager;
grant all on hr.jobs to hr_manager;
grant all on hr.employees to hr_manager;

El tercer rol se da el Rol de HR_SENIOR con la capacidad de transmitirlo, y luego toma el control total sobre el contenido de todas la Tablas. Pero tenga en cuenta que el único privilegio de este rol sea CREATE_SESSION, adquiridos atraves de HR_SENIOR, que adquirió a través de HR_JUNIOR. Ni siquiera este rol puede crear o eliminar tablas; que se debe hacer por sí mismo, o un administrador con CREATE ANY TABLE o DROP ANY TABLE.

Tenga en cuenta la sintaxis WITH ADMIN OPTION, que es la misma como para otorgar privilegios de sistemas. Como con privilegios de sistema, la revocación de un rol no en cascada. No hay ningún registro guardado de que se ha concedido un rol a quien.

Finalmente, conceder los roles al personal relevante, si SCOTT es un Administrador, SUe es un senior clerk y JON y ROOP es un junior clerks.

ROLES PREDEFINIDOS

Hay al menos 50 roles predefinidos en una Base de Datos Oracle (posiblemente muchos más, dependiendo sobre que opciones han sido instaladas). Unos que un DBA debe estar consciente son:

• CONNECT Este únicamente existe por compatibilidad atrás. En previas versiones, tenia los privilegios de sistema necesarios para crear objetos de almacenamiento de datos, tales como tablas; con las actuales versiones, solo tiene CREATE SESSION.

• RESOURCE también por compatibilidad atrás, este rol puede crear ambos objetos, objetos de datos (tales como tablas) y objetos de procedimientos (tales como procedimientos PL/SQL). También incluye UNLIMITED TABLESPACE.

• DBA tiene la mayoría de los privilegios de sistemas, y varios privilegios de objetos y roles. Cualquier usuario con DBA puede gestionar prácticamente todos los aspectos de la Base de Datos, excepto para inicio y parada.

• SELECT_CATALOG_ROLE tiene más de 2000 privilegios de objetos contra el diccionario de datos de objetos, pero no privilegios de sistema o privilegios contra datos del usuario. Útiles para administradores junior que deben monitorear y reportar sobre la Base de Datos pero no ser capaz de ver los datos de los usuarios.

• SCHEDULER_ADMIN tiene los privilegios necesarios para gestionar el servicio de programación e Jobs.

Hay también predefinido un Rol público, que siempre es otorgado a cada cuenta de usuario de Base de Datos. Sigue que si un privilegio es otorgado a PUBLIC, estará disponible para todos los usuarios. Así pues siguiendo este orden:

grant select on hr.regions to public;


Todos los usuarios serán capaces de consultar la Tabla HR.REGIONS.


EN EL TRABAJO

El Rol PUBLIC es tratado diferente de cualquier otro Rol. No hace, por ejemplo, aparezca en la vista DBA_ROLES. Esto se debe a que el código fuente de DBA_ROLES, que se puede ver en el script cdsec.sql llamado por el script catalog.sql, la excluye específicamente.

HABILITACION DE ROLES

Por default, si un usuario se le ha concedido un Rol, entonces el rol se habilitara. Esto significa que el momento que una sesión establece una conexión a la cuenta de usuario, todos los privilegios (y otros Roles) otorgados al Rol se activarán. Este comportamiento puede ser modificado haciendo el Rol non-default. Siguiendo el ejemplo dado en la sección precedente, esta consulta muestra que Roles han sido concedidos a JON:

SQL> select * from dba_role_privs where grantee='JON';
GRANTEE GRANTED_ROLE ADM DEF
----------------------------- --------------- --- ---
JON HR_JUNIOR NO YES

A JON ha sido otorgado HR_JUNIOR. El no tiene la administración en el ROL (así que él no puede pasarlo a cualquier persona), pero es un Rol default, el tendrá este Rol cada vez que se conecta. Esta situación no bien puede ser lo que usted quiere. Por ejemplo, JON tiene que ser capaz para ver las Tablas de HR (en su trabajo) pero eso no significa que usted quiera que él sea capaz marcar desde casa, a media noche, y hackear a las tablas con SQL * Plus. Usted quiere arreglar las cosas de tal manera que él pueda sol ver las tablas cuando se encuentra en una terminal en la oficina de personal, ejecutando la aplicación de HR, en horas de trabajo. Para cambiar el comportamiento por defecto:

alter user jon default role none;


Ahora cuando JON inicie sesión, no tendrá ningún rol habilitado. Desafortunadamente, esto significa que no puede iniciar sesión en lo absoluto, porque solo HR_JUNIO da privilegio de sistema CRETA_SESSION. Puede arreglar fácilmente.


SQL> grant connect to jon;
Grant succeeded.
SQL> alter user jon default role connect;
User altered.
SQL> select * from dba_role_privs where grantee='JON';
GRANTEE GRANTED_ROLE ADM DEF
------------------------------ --------------- --- ---
JON HR_JUNIOR NO NO
JON CONNECT NO YES

Ahora cuando JON se conecte, solo el Rol CONNECT es habilitado. Y la versión actual de CONNECT no es peligrosa en lo absoluto. Dentro de la aplicación, los comandos de software puede ser integrados para que el Rol HR_JUNIO. El comando básico para habilitar un Rol dentro de una sesión es:

SET ROLE rolename ;

Que puede ser emitido por el usuario en cualquier momento. Así que no hay seguridad todavía. Pero si el rol es creado con esta sintaxis:

CREATE ROLE rolename IDENTIFIED USING procedure_name ;

Entonces, el rol solo puede ser habilitado mediante la ejecución del procedimiento PL/SQL nominado por procedure_name. Esto procedimiento puede hacer cualquier numero de controles, tales como que el usuario está trabajando en una determinada subred TCP/IP; que se está ejecutando un procedo de usuario en particular (probablemente no en SQL*PLUS); que el tiempo está en un cierto rango; y así sucesivamente. Incorporación de las llamadas a los procedimientos que habilitan en los lugares adecuados en una aplicación puede cambiar de rol dentro y fuera como sea necesario, mientras que los deja inhabilitados siempre cuando una conexión se hace con una herramienta ad hoc del SQL tal como SQL*Plus.

EN EL TRABAJO

Puede ser muy difícil resolver como un usuario puede ver ciertos datos. Puede haber sido concedido un SELECT específico; puede haber sido concedido ALL; puede tener SELECT ANY; SELECT puede haber sido concedido a PUBLIC; puede tener un rol al que SELECT ha sido concedido. Puede tener todos estos, en el que todos tendrían que revocados para detener para que vea sus datos.

EJERCICIO 8-3.
CREAR Y OTORGAR ROLES.
En este ejercicio, creará algunos roles, otorgará ellos a los usuarios, y demostrar su eficacia.


1. Conéctese a su Base de Datos con SQL*PLUS como usuario SYSTEM.
2. Cree dos roles como sigue:
create role usr_role;
create role mgr_role;
3. Conceda algunos privilegios a los Roles, y conceda USR_ROLE a MGR_ROLE:
grant create session to usr_role;
grant select on alois.t1 to usr_role;
grant usr_role to mgr_role with admin option;
grant all on alois.t1 to mgr_role;
4. Como usuario SYSTEM, conceda los roles a AFRA y ANJA:
grant mgr_role to AFRA;
5. Conectse a la Base de Datos como AFRA:
connect afra/oracle;
6. Conceda el USR_ROLE a ANJA, e inserte una fila en ALOIS.T1:
grant usr_role to anja;
insert into alois.t1 values(sysdate);
commit;

7. Confirme a ANJA se puede conectar y consulte ALIOS.t1 pero no hacer nada mas:

connect anja/oracle
select * from alois.t1;
insert into alois.t1 values(sysdate);

8. Como usuario SYSTEM, modifique ANJA asi que por defecto se puede iniciar la session pero no hacen nada mas:

connect system/oracle
grant connect to anja;
alter user anja default role connect;
9. Mostrar la habilitación y des habilitación de los roles.
connect anja/oracle
select * from alois.t1;
set role usr_role;
select * from alois.t1;

10. Utilice el Database Control para inspeccionar los roles. La ruta de navegación es: en la ficha Server dar clic en el link Roles en la sección de Security. Haga clic en los enlaces para las dos nuevas funciones para ver a sus privilegios. Esta ilustración muestra la MGR_ROLE:

11. Para considerar a quien un Rol ha sido concedido, en el cuadro desplegable Acciones se muestra en la ilustración anterior, seleccione Mostrar los concesionarios y haga clic en el botón Go. Esta ilustración muestra el resultado de USR_ROLE:

12. Obtener la misma información recuperada en los pasos 10 y 11 con estos querys.
select * from dba_role_privs where granted_role in ('USR_ROLE','MGR_ROLE');
select grantee,owner,table_name,privilege,grantable from dba_tab_privs where grantee in ('USR_ROLE','MGR_ROLE')
union all
select grantee,to_char(null),to_char(null),privilege,admin_
option from dba_sys_privs where grantee in ('USR_ROLE','MGR_ROLE')
order by grantee;


OBJETIVO DE CERTIFICACION 8.04.
CREAR Y GESTIONAR PERFILES.

Un perfil tiene una doble función: para obligar una política de contraseñas y para restringir los recursos de una sesión pueda tomar. Los controles de contraseñas se hacen cumplir siempre; los límites de recursos se hacen cumplir solamente si el parámetro de instancia RESOURCE_LIMIT es verdadero. Por defecto, está en falso. Los perfiles son utilizados de forma automática, pero el perfil DEFAULT (aplicado por default a todos los usuarios, incluyendo SYS y SYSTEM) hace muy poco.

EXAMEN

Perfil limite contraseña siempre se hacen cumplir, Perfil limite de recursos son obligados únicamente si el parámetro de instancia RESOURCE_LIMIT es verdadero.

GESTION DE CONTRASEÑAS
Los límites que pueden ser aplicados a las contraseñas son:

• FAILED_LOGIN_ATTEMPTS especifica el número de errores consecutivos en una contraseña antes de que la cuenta está bloqueada. Si la contraseña es correcta antes este límite es alcanzado, el contador se ajustara a cero.

• PASSWORD_LOCK_TIME el número de días para Bloquear una cuenta después que FAILED_LOGIN_ATTEMPTS es alcanzado.

• PASSWORD_LIFE_TIME el número de días antes que una contraseña expire. Puede todavía ser usable después de este tiempo, dependiendo de PASSWORD_GRACE_TIME.

• PASSWORD_GRACE_TIME El número de días después de la primea conexión exitosa después que el Password ha caducado que le pide cambiar la contraseña será generada. El viejo Password es todavía usable durante este tiempo.

• PASSWORD_REUSE_TIME el número de días antes que una contraseña pueda ser reutilizada.

• PASSWORD_REUSE_MAX a continuación, el número de veces que una contraseña puede ser reutilizado.

• PASSWORD_VERIFY_FUNCTION el nombre de una función para ejecutar cada vez que una contraseña es modificado. El propósito de la función se asume para comprobar la nueva contraseña para requerir un grado de complejidad, pero puede hacer bastante mucho cualquier cosa que usted quiere.

LIMITES DE RECURSOS

Los límites que pueden ser aplicados al uso de recursos (también conocido como Kernel Limits) son:

• SESSIONS_PER_USER el número de conexiones concurrentes que puede ser hechas a la misma cuenta de usuario. Las sesiones intentan iniciar una sesión con el mismo nombre de usuario cuando este límite es alcanzado será bloqueado.

• CPU_PER_SESSION el tiempo de CPU (en centisegundos) que un proceso de servidor de una sesión está permitido a utilizar antes que la sesión es terminada por la fuerza.

• CPU_PER_CALL el tiempo de CPU (en centisegundos) que un proceso servidor de una sesión está permitido a utiliza para ejecutar una sentencia SQL antes que la sentencia sea forzada a terminar.

• LOGICAL_READS_PER_SESSION el numero de Blocks que pueden ser leídos por una sesión (Independientemente de si estaban en la caché del búfer de base de datos o leer desde el disco) antes que la sesión es forzada a terminar.

• LOGICAL_READS_PER_CALL el número de Blocks que pueden ser leídos por una única sentencia (independientemente de si están en el Database Buffer Cache o leídos desde disco) antes que la sentencia sea forzada a terminar.

• PRIVATE_SGA para sesiones conectadas atraves de la arquitectura Servidor compartido, el número de kilobytes que la sesión se le permite tomar en el SGA para los datos de la sesión.

• CONNECT_TIME en minutos, la duración máxima de una sesión antes que la sesión sea forzada a terminar.

• IDLE_TIME en minutos, el tiempo máximo de una sesión que puede estar ociosa antes de que la sesión se termine forzadamente.

• COMPOSITE_LIMIT una suma ponderada de CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION, y PRIVATE_SGA.

Los límites de recursos no se aplicaran a menos que un parámetro de instancia se ha establecido.

alter system set resource_limit=true;


Este por default es FALSE.

Cuando una sesión es terminada porque un límite de recursos ha sido alcanzado, si había una transacción en progreso será hecha roll back. Si una sentencia es terminada, el trabajo realizado por la sentencia sera Roolled back, pero cualquier declaración anterior seguirá siendo intacta y sin compromiso.

EN EL TRABAJO.

Los perfiles pueden ser utilizados para limitar el uso de recursos, pero una herramienta mucho más sofisticada es el Recource Manager.

DENTRO DEL EXAMEN
Administración de la Seguridad del Usuario.

La seguridad por defecto en una Base de Datos Oracle es de 100 porciento. Usted no puede incluso abrir una sesión sin el otorgamiento del permiso para hacerlo. No hay manera de conectase de forma anónima, aun que hay varias maneras de autentificarse. Una vez conectado a una cuenta de usuario, están limitadas por privilegiados y roles que han sido otorgados. Y por su cuota en Tablespace. Un rol es solo un conjunto de privilegios de objeto y sistema, pero a diferencia un privilegio otorgado directamente, un rol puede ser habilitado o deshabilitado dentro de una sesión.

Otorgar privilegios de sistema, privilegios de objetos y roles es similar en concepto, pero requiere una sintaxis ligeramente diferentes. La sintaxis para un REVOKE es idéntica. La revocación de un privilegio de objeto caerá en cascada, pero la revocación de un rol o un privilegio de sistema no lo harán.

Los perfiles pueden ser utilizados para obligar normas en Passwords y para control de los usuarios de los recursos se les permite tomar posesión en la Base de Datos.

CREANDO Y ASIGNANDO PERFILES.

Los perfiles pueden ser gestionados a través del Database Control o desde SQL*PLUS. Para mirar que perfil está asignado actualmente a cada usuario, ejecute esta consulta:

select username,profile from dba_users;

Por default , todos los usuarios (con la excepción de dos usuarios Internos, DBSNMP y WKSYS) tendrán asignado el Perfil llamado DEFAULT. Entonces las vista que mostrará los perfiles de ellos mismos es DBA_PROFILES:

select * from dba_profiles where profile='DEFAULT';

O con el Database Control, desde la pagina principal de la Base de Datos tomar la Ficha Server, y a continuación dar clic al Link Users en la sección de Seguridad para ver que Perfil cada usuario tiene. Seleccione un usuario y dar clic en el Botón Edit para asignar un Perfil diferente. Para ver como el Perfil está configurado. Dar clic en el Link Perfiles en la sección de Seguridad.

El perfil DEFAULT no tiene límites en recursos en los Absoluto, pero hay algunos límites en Password:

Estas restricciones no son muy estrictas: un Password puede ser ingresado incorrectamente diez veces consecutivas antes de que la cuenta sea bloqueada por un día, y un Password caducará después de seis meses con un periodo de gracia de una semana para cambiarlo después de eso.

La manera más simple para permitir una gestión más sofisticada de la contraseña es ejecutando un script proporcionado. En Unix o Linux es.

$ORACLE_HOME/rdbms/admin/utlpwdmg.sql


En Windows es.
%ORACLE_HOME%\rdbms\admin\utlpwdmg.sql

En cualquier plataforma, el script crea dos funciones llamadas VERIFY_FUNCTION y VERIFY_FUNCTION_11G, y se ejecuta este comando:

ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 180
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME 1
PASSWORD_VERIFY_FUNCTION verify_function_11G;

El comando ajustará el perfil llamado DEFAULT. Cualquier usuario con el perfil DEFAULT (que son todos los usuarios por default) inmediatamente recoger los nuevos valores. Despues de una creación de Base de Datos estándar, el único cambio será la especificación del PASSWORD_VERIFY_FUNCTION. La función nominada, VERIFY_FUNCTION_11G, hace un conjunto de pruebas simples y rechazará un cambio de Password sino pasa todos.

• El nuevo Password debe tener al menos ocho caracteres de Longitud.

• El nuevo Password no puede ser el mismo como el username (deletreado adelante o atrás) o el nombre de la Base de Datos, en mayúsculas o minúsculas.

• Un poco simple y Password utilizados comúnmente (tales como oracle) serán rechazada.
• El nuevo Password debe tener al menos una letra y por lo menos un digito.
• El Password debe diferir en al menos tres caracteres del Password anterior.


El script debe ser visto como un script de ejemplo (sin duda la función es muy elemental) y debe ser editado a las necesidades de la organización. La mayoría de las organizaciones necesitarán ir más allá que esto y crear un conjunto de perfiles para ser aplicados a diferentes usuarios.

Para crear un perfil con SQL*PLUS, utilice el comando CREATE PROFILE, establecer los límites de los que se requiere. Cualquier limite no especificado será cogido de la versión actual del perfil DEFAULT. Por ejemplo, podría ser que las normas de la organización indican que ninguno usuario debería ser capaz de iniciar sesión en más de una vez. Excepto para el personal de administración, quien puede iniciar sesión tantas sesiones concurrentes como ellos quieren y deben cambiar sus Password cada semana con un día de gracia. Y los programadores, que pueden conectarse dos veces. Para hacer esto, primero modifique el perfil DEFAULT:

alter profile default limit sessions_per_user 1;


Crear un Nuevo Perfil para los DBAs, y asignarle:


create profile dba_profile limit sessions_per_user unlimited
password_life_time 7 password_grace_time 1;
alter user sys profile dba_profile;
alter user system profile dba_profile;


Crear un perfil para los programadores, y asignarle:


create profile programmers_profile limit sessions_per_user 2;
alter user jon profile programmers_profile;
alter user sue profile programmers_profile;


Para permitir limitar los recursos tome efecto, modifique el parámetro de Instancia:


alter system set resource_limit=true;

Suponiendo que la instancia está utilizando un SPFILE, este cambio será propagado al archivo de parámetros y por lo tanto será permanente.

Un perfil no puede ser eliminado si se ha asignado a los usuarios. Debe ser alterado a un perfil diferente, una vez hecho, eliminar el perfil con:

DROP PROFILE profile_name;


Alternativamente, utilice esta sintaxis:
DROP PROFILE profile_name CASCADE;


Que automáticamente reasignará todos los usuarios con el profile_name de nuevo al perfil DEFAULT.