ORACLE DBA ADMINISTRACION DE BASE DE DATOS

ORACLE DBA ADMINISTRACION DE BASE DE DATOS
Dictado por: Ing. Carlos Alcalá Helguero Consultas:

ORACLE DBA TEMA 6 ADMINISTRACION DE USUARIOS Y SEGURIDAD EN BASES DE DATOS

ADMINISTRACION DE USUARIOS Y SEGURIDAD
Administración de Usuarios y Seguridad Authentication de Base de Datos Si se elige la autenticación por Base de Datos, la administración de la cuenta de usuario, el password, y la autenticación se realiza por medio de Oracle. Para autenticas un usuario, se debe especificar un password cuando se creo o modifica su cuenta. Los usuarios pueden cambiar sus password en cualquier momento. Los passwords se almacenan en formato encriptado. Cada password debe estar compuesto de caracteres tipo single-byte, incluso si la base de datos usa un set de caracteres multibyte. Para incrementar la seguridad cuando se usa la autenticación de base de datos, Oracle recomienda el uso de administración de password, incluyendo bloqueo de cuentas, caducidad de password y expiración, historial de password, y verificación de complejidad de password. Crear un usuario autenticado por Base de Datos La siguiente sentencia modifica un usuario que se identifica y se autentica por medio de Oracle. El usuario scott debe especificar el password “tigerwoods” cuando se conecte a Oracle: ALTER USER scoot IDENTIFIED BY tigerwoods; Administración de Usuarios Oracle Cada base de datos Oracle tiene una lista de usuarios validos. Para acceder a una base de datos, un usuario debe ejecutar una aplicación y conectarse a la instancia de base de datos utilizando un usuario valido definido con anterioridad.

Creación de Usuarios Se crea un usuario utilizando la sentencia CREATE USER. Para crear un usuario de base de datos, se debe tener el privilegio CREATE USER. Dado que este es un privilegio muy poderoso, un administrador de seguridad DBA es normalmente el único que tiene este privilegio. El siguiente ejemplo crea un usuario y especifica el password, espacio de tablas por defecto, espacio de tablas temporal donde se crean los segmentos temporales, las quotas de espacio de tablas, y el perfil de usuario. CREATE USER jward IDENTIFIED BY aZ7bC2 DEFAULT TABLESPACE data_ts QUOTA 100M ON test_ts QUOTA 500K ON data_ts TEMPORARY TABLESPACE temp_ts PROFILE clerk; GRANT connect TO jward; Un usuario nuevo que se crea en la base de datos no se puede conectar a la misma hasta que se le otorgue el privilegio CREATE SESSION. Usualmente un usuario nuevo que se crea se le otorga un rol, similar al rol predefinido CONNECT, como se muestra en este ejemplo, que especifica el privilegio CREATE SESSION así como otros privilegios básicos requeridos para acceder a la base de datos.

Especificar un nombre Dentro de cada base de datos un nombre de usuario debe ser único respecto a los otros existentes y los roles. Un usuario y un rol no pueden tener el mismo nombre. Mas aun, cada usuario tiene asociado un esquema. Dentro del esquema, cada objeto debe tener un nombre único. Configurar Autenticacion de Usuario En la sentencia anterior CREATE USER, el Nuevo usuario esta por ser autenticado por medio de Oracle. En este caso, el usuario a conectarse debe ingresar el password correcto para conectarse exitosamente. Asignar un Espacio de Tablas por Defecto Cada usuario debe tener un espacio de tablas por defecto. Cuando un usuario crea un objeto de esquema y no especifica el espacio de tablas para contenedor, Oracle guarda el objeto en el espacio de tablas por defecto. El espacio de tablas configurado por defecto para cada usuario es el SYSTEM. Si un usuario no crea objetos, y no tiene privilegios para hacerlo, esta configuración por defecto esta bien. Sin embargo, si un usuario crea cualquier tipo de objeto, se debe especificar un espacio de tablas. Usar otro espacio de tablas diferente del SYSTEM reduce la contencion entre los datos de diccionario y los datos de los objetos de usuario.

Se puede configurar el espacio de tablas por defecto al momento de la creación del usuario, y cambiar después con la sentencia ALTER USER. Cambiar el espacio de tablas por defecto afecta solo a los objetos creados después de cambiar la configuración. Cuando se especifica el espacio de tablas por defecto, también se especifica una cuota en ese espacio. En la sentencia anterior CREATE USER, el espacio de tablas para el usuario jward es data_ts, y su cuota es de 500K. Asignar un Espacio de Tablas Temporal Cada usuario también tiene asignado un espacio de tablas temporal. Cuando el usuario ejecuta una sentencia SQL requiere un segmento temporal, Oracle guarda el segmento en el espacio de tablas temporal. Este espacio de tablas temporal son creados por el sistema cuando se realizan sorts o joins y son propiedad del usuario SYS, que tiene privilegios de recursos en todos los espacios de tablas. En la sentencia previa CREATE USER, el espacio temporal de tablas es temp_ts, un espacio de tablas creado especialmente para contener segmentos temporales. Tal espacio de tablas es creado usando la sentencia CREATE TEMPORARY TABLESPACE. Si no se especifica el espacio de tablas por defecto, se le asigna por defecto el que esta especificado en la creación de la base de datos, o por medio de la sentencia ALTER DATABASE después. Si no hay ningún espacio de tablas temporal, se usa el SYSTEM. Se puede cambiar el espacio de tablas por defecto usando la sentencia ALTER USER. No se debe configurar la cuota de usuario en espacios de tablas temporal.

Especificar un Perfil de Usuario Se especifica un perfil de usuario cuando se crea uno. Un perfil es una serie de límites en los recursos de la base de datos y acceso de password a la misma. Si no se especifica un perfil, se le asigna el perfil por defecto. Configurar Roles por Defecto No se puede configurar el rol por defecto del usuario en la sentencia CREATE USER. Cuando se crea un usuario, el rol por defecto es ALL, que causa que todos los roles asignados al usuario a ser roles por defecto. Se debe usar la sentencia ALTER USER para cambiar los roles por defecto. Cambiar Usuarios Los usuarios pueden cambiar sus propios password. Sin embargo, para cambiar alguna opción de seguridad de un dominio del usuario, se debe tener el privilegio ALTER USER. Los administradores de seguridad son los únicos que normalmente tienen este privilegio. Este privilegio incluye la habilidad para establecer cuotas de usuario en un espacio de tablas, incluso si el usuario que realiza la modificación no tiene una cuota.

La siguiente sentencia cambia las opciones de seguridad para el usuario cursodba: ALTER USER cursodba DEFAULT TABLESPACE data_ts TEMPORARY TABLESPACE temp_ts QUOTA 100M ON data_ts QUOTA 0 ON test_ts5 PROFILE admindba; La sentencia ALTER USER aquí cambia las opciones de seguridad del usuario de la siguiente manera: La autenticación se cambia para ser por sistema operativo (IDENTIFIED EXTERNALLY) Se especifica el espacio de tablas temporal por defecto (TEMPORARY TABLESPACE temp_ts) Se le da una cuota de usuario para el espacio de tablas data_ts de 100M La cuota de usuario en el espacio de tablas test_ts se reboca. Se le asigna el perfil creado previamente admindba

Cambiar el mecanismo de autenticación La mayoría de los usuarios que no son DBA puede cambiar sus propios password con la sentencia ALTER USER Por ejemplo: ALTER USER cursodba IDENTIFIED BY swordfish; Los usuarios pueden cambiar sus propios password de esta manera, sin tener ningún privilegio especial. Como medida de seguridad los usuarios deben cambiar sus password frecuentemente. Los usuarios deben tener el privilegio ALTER USER para cambiar entre la autenticación de Oracle y autenticación externa. Usualmente, solo un administrador tiene este privilegio. Borrar usuarios Cuando un usuario es eliminado, el usuario y el esquema asociado son removidos del diccionario de datos y todos los objetos de esquema contenidos, son eliminados inmediatamente. Un usuario que esta actualmente conectado a la base de datos no puede eliminarse. Para borrar a un usuario conectado, se debe primero terminar con la sesión del usuario usando la sentencia SQL de ALTER SYSTEM con la opción KILL SESSION.

Se puede borrar a un usuario con la sentencia DROP USER. Si el usuario contiene algún objeto de esquema asociado, usar la opción CASCADE para borrar al usuario. Si no se especifica la opción CASCADE y el usuario tiene objetos de esquema asociados, un mensaje de error se retorna y el usuario no se borra. Antes de borrar un usuario que tiene objetos de esquema, se debe investigar que objetos contiene y cuales las implicaciones de eliminarlos. Prestar atención a los efectos en cascada. Por ejemplo, si se intenta borrar un usuario que es propietario de una tabla, verificar que vistas o procesos dependen de aquella tabla en particular. La siguiente sentencia borra al usuario jones y todos los objetos asociados y llaves foráneas que dependen de las tablas propiedad de jones. DROP USER jones CASCADE;

Administración de Recursos y Perfiles Un perfil es una seria de límites de recursos. Los limites de uso de recursos e instancias de un usuario se definen en el perfil de usuario. Se puede asignar un perfil a cada usuario, y un perfil por defecto a todos los usuarios que no tienen perfiles por defecto. Para que los perfiles tengan efecto, los limites de recursos deben estar habilitados para toda la base de datos. Habilitar o Deshabilitar los limites de recursos Si una base de datos no se puede finalizar temporalmente o la característica de limite de recursos se debe cambiar temporalmente, se puede habilitar o deshabilitar esta opción con la sentencia ALTER SYSTEM. Después que se inicia la instancia, una sentencia ALTER SYSTEM sobrescribe el valor fijado por el parámetro de inicio RESOURCE_LIMIT. Por ejemplo, la siguiente sentencia habilita los límites de recursos para una base de datos: ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;

Creación de Perfiles Para crear un perfil, se debe tener el privilegio CREATE PROFILE. Se puede crear perfiles con esa sentencia al mismo tiempo se puede especificar los limites de recursos. La siguiente sentencia nos muestra como crear el perfil admindba: CREATE PROFILE admindba LIMIT SESSIONS_PER_USER 2 CPU_PER_SESSION unlimited CPU_PER_CALL 6000 LOGICAL_READS_PER_SESSION unlimited LOGICAL_READS_PER_CALL 100 IDLE_TIME 30 CONNECT_TIME 480; Todos los límites de recursos para un nuevo perfil toman el valor de un perfil DEFAULT. Cada base de datos tiene su perfil DEFAULT, y se usan en dos casos: Si el usuario no es asignado explícitamente a un perfil, se conforma a todos los limites del perfil DEFAULT Todos los limites no especificados de cualquier perfil toman los valores del perfil DEFAULT

Inicialmente, todos los limites en el perfil DEFAULT están establecidos en UNLIMITED. Sin embargo, para prevenir el consumo de recursos de los usuario del perfil DEFAULT, se deben cambiar los limites por defecto usando la sentencia ALTER PROFILE: ALTER PROFILE default LIMIT ...; Cualquier usuario con el privilegio ALTER PROFILE puede ajustar los limites en el perfil DEFAULT. El perfil DEFAULT no se puede eliminar. Asignación de Perfiles Después de crear un perfil, se puede asignar a los usuarios de la base de datos. Cada usuario se puede asignar solo un perfil por ves. Si un perfil se le asigna a un usuario que ya tiene un perfil, la nueva asignación sobrescribe el previamente asignado. La asignación de perfiles no afectan las sesiones actuales. Los perfiles pueden ser asignados solo a usuarios, no a roles u otros perfiles.

Cambio de Perfiles Se puede cambiar la configuración de límites de un perfil usando la sentencia ALTER PROFILE. Cualquier cambio a los límites del perfil sobrescribe los valores previos. Ajustando los valores de límites con valor DEFAULT, el límite de recursos se revierte a los valores por defecto para la base de datos. Todos los perfiles que no estén ajustados cuando se cambia el perfil retienen los valores previos. Cualquier cambio a un perfil no afecta las sesiones actuales. Los nuevos valores de límites son usados por sesiones creadas después que se modifica el perfil. La siguiente sentencia modifica el perfil admindba: ALTER PROFILE admindba LIMIT CPU_PER_CALL default LOGICAL_READS_PER_SESSION 20000;

Borrar Perfiles Para borrar un perfil, se debe tener el privilegio DROP PROFILE. Se puede borrar un perfil usando la sentencia DROP PROFILE. Para borrar exitosamente un perfil que esta asignado a un usuario, usar la opción CASCADE. La siguiente sentencia borra el perfil pruebaperfil, incluso si se asigna a un usuario: DROP PROFILE pruebaperfil CASCADE; Cualquier usuario asignado a un perfil que se elimina se asigna automáticamente al perfil DEFAULT. El perfil DEFAULT no se puede borrar. Cuando un perfil se borra, esto no afecta a las sesiones actuales. Solo a las sesiones creadas después que se borra el perfil.

Ver información sobre Usuarios de Base de Datos y Perfiles Las siguientes consultas muestran algunas vistas e información sobre usuarios, para lo cual se definen los siguientes perfiles y usuarios: CREATE PROFILE perfilba LIMIT SESSIONS_PER_USER 1 IDLE_TIME 30 CONNECT_TIME 600; CREATE USER pruebadba IDENTIFIED BY wildcat DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp_ts QUOTA 500K ON users PROFILE perfildba; CREATE USER cursodba IDENTIFIED BY bedrock QUOTA unlimited ON users; CREATE USER userscott IDENTIFIED BY scott1;

Listar todos los usuarios e información asociada La siguiente sentencia muestra todos los usuarios y su información asociada como se define en la base de datos: SELECT USERNAME, PROFILE, ACCOUNT_STATUS FROM DBA_USERS; USERNAME PROFILE ACCOUNT_STATUS SYS DEFAULT OPEN SYSTEM DEFAULT OPEN USERSCOTT DEFAULT OPEN PRUEBADBA PERFILDBA OPEN CURSODBA DEFAULT OPEN Todos los password estan encriptados para preservar la seguridad. Si un usuario consulta la columna PASSWORD, ese usuario no será capaz de determinar el password de otro usuario.

Listar las cuotas espacios de tablas Las siguientes consultas listan todas las cuotas específicamente asignadas para cada usuario: SELECT * FROM DBA_TS_QUOTAS; TABLESPACE USERNAME BYTES MAX_BYTES BLOCKS MAX_BLOCKS USERS PRUEBADBA USERS CURSODBA Cuando se asigna cuotas específicamente, el número exacto se indica en la columna MAX_BYTES. Note que este número es siempre múltiplo del tamaño de bloque de la base de datos, así que si se especifica una cuota de espacio de tablas que no es múltiplo del tamaño de bloque, se redondea hacia el valor superior correcto. Cuotas ilimitadas se indican por el valor "-1".

Listar todos los perfiles y Límites asignados La siguiente consulta lista todos los perfiles en la base de datos y los valores asociados para cada límite en cada perfil: SELECT * FROM DBA_PROFILES ORDER BY PROFILE; PROFILE RESOURCE_NAME RESOURCE LIMIT PERFILDBADBA COMPOSITE_LIMIT KERNEL DEFAULT PERFILDBADBA FAILED_LOGIN_ATTEMPTS PASSWORD DEFAULT PERFILDBADBA PASSWORD_LIFE_TIME PASSWORD DEFAULT PERFILDBADBA PASSWORD_REUSE_TIME PASSWORD DEFAULT PERFILDBADBA PASSWORD_REUSE_MAX PASSWORD DEFAULT PERFILDBADBA PASSWORD_VERIFY_FUNCTION PASSWORD DEFAULT PERFILDBADBA PASSWORD_LOCK_TIME PASSWORD DEFAULT PERFILDBADBA PASSWORD_GRACE_TIME PASSWORD DEFAULT PERFILDBADBA PRIVATE_SGA KERNEL DEFAULT PERFILDBADBA CONNECT_TIME KERNEL 600 PERFILDBADBA IDLE_TIME KERNEL 30 PERFILDBADBA LOGICAL_READS_PER_CALL KERNEL DEFAULT PERFILDBADBA LOGICAL_READS_PER_SESSION KERNEL DEFAULT PERFILDBADBA CPU_PER_CALL KERNEL DEFAULT PERFILDBADBA CPU_PER_SESSION KERNEL DEFAULT PERFILDBADBA SESSIONS_PER_USER KERNEL 1

DEFAULT COMPOSITE_LIMIT KERNEL UNLIMITED DEFAULT PRIVATE_SGA KERNEL UNLIMITED DEFAULT SESSIONS_PER_USER KERNEL UNLIMITED DEFAULT CPU_PER_CALL KERNEL UNLIMITED DEFAULT LOGICAL_READS_PER_CALL KERNEL UNLIMITED DEFAULT CONNECT_TIME KERNEL UNLIMITED DEFAULT IDLE_TIME KERNEL UNLIMITED DEFAULT LOGICAL_READS_PER_SESSION KERNEL UNLIMITED DEFAULT CPU_PER_SESSION KERNEL UNLIMITED DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD UNLIMITE DEFAULT PASSWORD_LIFE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED DEFAULT PASSWORD_LOCK_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_GRACE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED 32 rows selected

Verificar uso de memoria para cada sesión de usuario La siguiente consulta lista todas las sesiones actuales, mostrando el usuario Oracle y su actual UGA (user global area) memoria para cada sesión: SELECT USERNAME, VALUE || 'bytes' "Current UGA memory" FROM V$SESSION sess, V$SESSTAT stat, V$STATNAME name WHERE sess.SID = stat.SID AND stat.STATISTIC# = name.STATISTIC# AND name.NAME = 'session uga memory'; USERNAME Current UGA memory 18636bytes 17464bytes 19180bytes 18364bytes 39384bytes 35292bytes 17696bytes 15868bytes USERSCOTT byte SYS bytes SYSTEM bytes 11 rows selected. Para ver el máximo de memoria UGA que se haya reservado para cada sesión desde el inicio de la instancia, reemplazar 'session uga memory' en la consulta de arriba por 'session uga memory max'.

PRIVILEGIOS Y ROLES DE USUARIO
Administración de Privilegios y Roles En esta sección se explica como usar privilegios y roles para controlar el acceso a objetos de esquema y controlar la habilidad para ejecutar operaciones de sistema. Un privilegio de usuario es un derecho a ejecutar cierto tipo de sentencia SQL, o derecho de acceder a los objetos de otros usuarios. Privilegios de Sistema Existen cerca de 100 privilegios distintos de sistema. Cada privilegio permite al usuario realizar una operación particular sobre la base de datos. Para una lista completa, incluyendo descripciones, ver: Oracle9i SQL Reference. Restricciones de Privilegios de sistema Dado que los privilegios de sistema son muy poderosos, Oracle recomienda que se configure la base de datos para prevenir que usuarios regulares (no-DBA) puedan ejecutar NINGUNO de los privilegios de sistema (tal como UPDATE ANY TABLE) en el diccionario de datos. En orden de asegurar el diccionario de datos, el parámetro de inicialización O7_DICTIONARY_ACCESSIBILITY debe estar establecido como FALSE. Esta característica es llamada mecanismo de protección del diccionario de datos.

Acceder a Objetos en el esquema SYS Usuarios con privilegios explícitos de objeto o con privilegios administrativos (SYSDBA) pueden acceder objetos en el esquema SYS. Otra forma de permitir el acceso a los objetos del esquema SYS es otorgando a los usuarios uno de los siguientes roles: SELECT_CATALOG_ROLE. Este rol puede ser otorgado a los usuarios para los privilegios de SELECT en todas las vistas de diccionario de datos. EXECUTE_CATALOG_ROLE. Este rol puede ser otorgado a los usuarios para privilegios de EXECUTE en los paquetes y procedimientos del diccionario de datos. DELETE_CATALOG_ROLE. Este rol permite borrar registros de la tabla de auditoria de sistema (AUD$). Adicionalmente, el siguiente privilegio de sistema puede ser otorgado a los usuarios que requieran acceso a los objetos creados en el esquema SYS: SELECT ANY DICTIONARY. Este privilegio permite consultar cualquier objeto en el esquema SYS, incluyendo tablas creadas.

Privilegios de Objeto Cada tipo de objeto tiene diferentes privilegios asociados con el. Para una lista detallada de objetos y sus privilegios asociados, ver Oracle9i SQL Reference. Se puede especificar ALL [PRIVILEGES] para otorgar o revocar todos los privilegios de objeto para un objeto. ALL no es un privilegio; en lugar de eso es un acceso directo, o una manera de otorgar o revocar privilegios con una sola palabra en las sentencias GRANT y REVOKE. Notar que si todos los privilegios son otorgados con usando ALL, los privilegios individuales pueden ser removidos. De igual manera, todos los privilegios otorgados individualmente pueden ser revocados usando ALL. Sin embargo, se usa el REVOKE ALL, y revocar causa que se borren los constraints de integridad (porque dependen de del privilegio REFERENCES que se esta revocando), se debe incluir la opción CASCADE CONSTRAINTS en la sentencia REVOKE. Administración de Roles Un rol agrupa muchos privilegios y otros roles, por lo que pueden ser otorgados y revocados de usuarios simultáneamente. Un rol debe estar habilitado antes de ser usado.

Roles Predefinidos Los roles listados en la tabla a continuación son automáticamente definidos par las bases de datos Oracle cuando se ejecutan los scripts estándar que son parte de la creación de la base de datos. Puede otorgar privilegios y roles hacia, y revocar privilegios y roles desde, los roles predefinidos, de la forma que haría con cualquier rol que defina. CONNECT SQL.BSQ Incluye los siguientes privilegios: ALTER SESSION, CREATE CLUSTER, CREATE DATABASE LINK, CREATE SEQUENCE, CREATE SESSION, CREATE SYNONYM, CREATE TABLE, CREATE VIEW RESOURCE CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER, CREATE TYPE

DBA SQL.BSQ All system privileges WITH ADMIN OPTION Note: The previous three roles are provided to maintain compatibility with previous versions of Oracle and may not be created automatically in future versions of Oracle. Oracle Corporation recommends that you design your own roles for database security, rather than relying on these roles. EXP_FULL_DATABASE CATEXP.SQL Provides the privileges required to perform full and incremental database exports. Includes: SELECT ANY TABLE, BACKUP ANY TABLE, EXECUTE ANY PROCEDURE, EXECUTE ANY TYPE, ADMINISTER RESOURCE MANAGER, and INSERT, DELETE, and UPDATE on the tables SYS.INCVID, SYS.INCFIL, and SYS.INCEXP. Also the following roles: EXECUTE_CATALOG_ROLE and SELECT_ CATALOG_ROLE. IMP_FULL_DATABASE CATEXP.SQL Provee los privielgios para realizar importación completa de base de datos. Incluye una extensiva lista de privilegios de sistema (usar vista DBA_ SYS_PRIVS para ver los privilegios) y los siguientes roles: EXECUTE_CATALOG_ROLE and SELECT_CATALOG_ROLE. DELETE_CATALOG_ROLE Provides DELETE privilege on the system audit table (AUD$) EXECUTE_CATALOG_ROLE Provides EXECUTE privilege on objects in the data dictionary. Also, HS_ADMIN_ROLE. SELECT_CATALOG_ROLE Provides SELECT privilege on objects in the data dictionary. Also, HS_ADMIN_ROLE.

RECOVERY_CATALOG_OWNER CATALOG.SQL Provides privileges for owner of the recovery catalog. Includes: CREATE SESSION, ALTER SESSION, CREATE SYNONYM, CREATE VIEW, CREATE DATABASE LINK, CREATE TABLE, CREATE CLUSTER, CREATE SEQUENCE, CREATE TRIGGER, and CREATE PROCEDURE HS_ADMIN_ROLE CATHS.SQL Used to protect access to the HS (Heterogeneous Services) data dictionary tables (grants SELECT) and packages (grants EXECUTE). It is granted to SELECT_ CATALOG_ROLE and EXECUTE_CATALOG_ ROLE such that users with generic data dictionary access also can access the HS data dictionary. AQ_USER_ROLE CATQUEUE.SQL Obsoleted, but kept mainly for release 8.0 compatibility. Provides execute privilege on DBMS_AQ and DBMS_AQIN. AQ_ADMINISTRATOR_ROLE Provides privileges to administer Advance Queuing. Includes ENQUEUE ANY QUEUE, DEQUEUE ANY QUEUE, and MANAGE ANY QUEUE, SELECT privileges on AQ tables and EXECUTE privileges on AQ packages. SNMPAGENT CATSNMP.SQL This role is used by Enterprise Manager/Intelligent Agent. Includes ANALYZE ANY and grants SELECT on various views.

Crear un Rol Puede crear un rol usando la sentencia CREATE ROLE, pero se debe tener el privilegio CREATE ROLE. Se debe dar a cada rol creado un único nombre entre los nombres de usuarios y roles de la base de datos. Los roles no están contenidos en el esquema de ningún usuario. En una base de datos que use un set de caracteres multibyte, Oracle recomienda que cada rol contenga al menos un carácter de tipo single-byte. Si el rol contiene solo caracteres multibyte, el nombre/password encriptado se considera menos seguro. La siguiente sentencia crea el rol admindba, que esta autorizado por la base de datos usando el password milenium: CREATE ROLE admindba IDENTIFIED BY milenium; La cláusula IDENTIFIED BY especifica como el usuario debe estar autorizado antes que le rol sea habilitado para su uso por un usuario especifico al cual ha sido otorgado. Si no se especifica esta clausula, o se especifica NOT IDENTIFIED, entonces no se require autorizacion cuando se habilita el rol. Los roles pueden ser autorizados por: La base de datos usando un password Una aplicación usando un paquete especifico Externamente por el sistema operativo, red u otro recurso Globalmente por medio del servicio de directorio Luego, se puede cambiar el metodo de autenticacion para un rol usando la sentencia ALTER ROLE. La siguiente sentencia cambia el rol admindba para especificar que el usuario debe estar autorizado por una fuente externa antes de habilitar el rol: ALTER ROLE admindba IDENTIFIED EXTERNALLY;

Autorización de Rol por Base de Datos El uso de un rol autorizado por la base de datos puede estar protegido por un password asociado. Si se le otorga un rol protegido por un password, se puede habilitar o deshabilitar el rol ingresando el password para el rol con la sentencia SET ROLE. Sin embargo, pero si el rol es por defecto y esta habilitado al tiempo de conexión, el usuario no requiere ingresar el password. La siguiente sentencia crea el rol manager. Cuando esta habilitado el password morework debe ser ingresado: CREATE ROLE manager IDENTIFIED BY morework; Autorización de Rol por Aplicación La cláusula INDENTIFIED USING package_name permite crear un rol de aplicación, que es un rol que puede ser habilitado solo por aplicaciones usando un paquete autorizado. Los desarrolladores de aplicaciones no necesitan asegurar un rol integrando password dentro de las aplicaciones. Si no, se pueden crear roles de aplicaciones y especificar que paquete de PL/SQL es autorizado para habilitar el rol. El siguiente ejemplo indica que el rol admin_role es un rol de aplicación y solo puede ser habilitado por cualquier modulo definido dentro del paquete PL/SQL hr.admin: CREATE ROLE admin_role IDENTIFIED USING hr.admin;

Borrar Roles En algunos casos, es apropiado borrar un rol de una base de datos. Los dominios de seguridad de todos los usuarios y roles otorgados de un rol borrado son inmediatamente cambiados para reflejar la ausencia del rol eliminado. Todos los roles indirectamente otorgados del rol eliminado también son eliminados de los dominios de seguridad afectados. Borrar un rol automáticamente remueve el mismo de la lista de roles por defecto. Dado que la creación de objetos no es dependiente no es dependiente en los privilegios recibidos a través del rol, tablas y otros objetos no son eliminados cuando se elimina un rol. Se puede borrar un rol usando la sentencia SQL de DROP ROLE. Para borrar un rol se debe tener el privilegio DROP ANY ROLE o tener el rol con la opción ADMIN OPTION. La siguiente sentencia borra el rol admindba: DROP ROLE admindba; Otorgar Privilegios de Usuario y Roles Se puede otorgar privilegios de usuario y roles a otros roles y usuarios usando la sentencia SQL de GRANT. Para otorgar un privilegio de sistema o rol, se debe tener la opción ADMIN OPTION para todos los privilegios y roles que se otorguen. También, cualquier usuario con el privilegio GRANT ANY ROLE puede otorgar un rol en la base de datos. La siguiente sentencia otorga el privilegio CREATE SESSION y el rol accts_pay al usuario jward: GRANT CREATE SESSION, accts_pay TO jward

Cuando un usuario crea un rol, el rol es automáticamente otorgado al creador con la opción ADMIN OPTION. Las ventajas son las siguientes: El propietario puede otorgar o revocar el privilegio o rol hacia cualquier usuario o rol en la base de datos. Usuarios no pueden revocar roles de si mismos. EL propietario puede otorgar el privilegio o rol con la opción ADMIN OPTION. El propietario puede cambiar o borrar el rol. En la siguiente sentencia, el administrador otorga el rol new_dba al usuario michael: GRANT new_dba TO michael WITH ADMIN OPTION; El usuario michael no solo puede usar todos los privilegios implícitos en el rol otorgado new_dba, también puede otorgar, revocar o eliminar el rol new_dba de los usuarios según sea necesario. Debido a estas capacidades, se debe ejercitar precaución cuando se otorga privilegios o roles con la opción ADMIN OPTION. Estos privilegios son usualmente reservados para un administrador de seguridad y raramente es otorgado a otros usuarios en el sistema.

Otorgar Privilegios de Objeto y Roles También se usa la sentencia GRANT para otorgar privilegios de objeto hacia roles y usuarios. Para otorgar un privilegio de objeto, se debe satisfacer las siguientes condiciones: El usuario es propietario del objeto especificado Tiene el privilegio de GRANT OPTION. La siguiente sentencia otorga los privilegios de objetos SELECT, INSERT, y DELETE para todas las columnas de la tabla emp a los usuarios jfee y tsmith: GRANT SELECT, INSERT, DELETE ON emp TO jfee, tsmith; Para otorgar el privilegio INSERT solo para las columnas ename y job de la tabla emp a los usuarios jef y tsmith, ejecutar la siguiente consulta: GRANT INSERT(ename, job) ON emp TO jfee, tsmith; Para otorgar todos los privilegios en la vista salary al usuario jfee, se debe usar la palabra reservada ALL, como se muestra a continuación: GRANT ALL ON salary TO jfee;

Revocar privilegios y Roles Se puede revocar privilegios y roles usando la sentencia SQL de REVOKE. Cualquier usuario con el privilegio ADMIN OPTION puede revocar un privilegio o rol de cualquier usuario o rol de la base de datos. El revocador no tiene que ser el usuario que originalmente otorgo el privilegio o rol. También, usuarios con el privilegio GRANT ANY ROLE pueden revocar cualquier rol. La siguiente sentencia revoca el privilegio CREATE TABLE y el rol accts_rec del usuario tsmith: REVOKE CREATE TABLE, accts_rec FROM tsmith; Revocar Privilegios de Objeto y Roles La sentencia REVOKE es usada para revocar privilegios de objeto. Para revocar un privilegio de objeto, el que revoca debe ser el que originalmente otorgo el privilegio que se quiere revocar. Por ejemplo, asumiendo que es el que otorgo originalmente, para revocar los privilegios SELECT e INSERT en la tabla emp de los usuarios jfee y tsmith, se debe ejecutar la siguiente sentencia: REVOKE SELECT, insert ON emp FROM jfee, tsmith; La siguiente sentencia revoca todos los privilegios (que originalmente están otorgados al rol human_resource) de la tabla dept: REVOKE ALL ON dept FROM human_resources;

Revocando privilegios de columnas Aunque usuarios pueden otorgar privilegios selectivos a columnas como INSERT, UPDATE, y REFERENCES para tablas y vistas, no se puede revocar selectivamente a las columnas especificas con una sentencia similar REVOKE. En su lugar, el usuario debe primero revocar el privilegio de objeto para todas las columnas de uan tabla o vista, y luego selectivamente reotorgar privilegios a columnas especificas que se quedaran así. Por ejemplo, asumiendo que el rol human_resources a sido otorgado con el privilegios UPDATE en la columna deptno y dname de la tabla dept. Para revocar el privilegio UPDATE en la columna deptno, se debe ejecutar los siguientes dos sentencias: REVOKE UPDATE ON dept FROM human_resources; GRANT UPDATE (dname) ON dept TO human_resources; Para revocar la sentencia REVOKE revoca el privilegio UPDATE en todas las columnas de la tabla dept del rol human_resources. La sentencia GRANT reotorga el privilegio UPDATE en la coluimna dname al rol human_resources. Revocar el privilegio REFERENCES Si se otorga el privilegio REFERENCES para crear una llave foranea (que existe actualmente), se puede revocar el privilegio solo especificando la opción CASCADE CONSTRAINTS en la sentencia REVOKE: REVOKE REFERENCES ON dept FROM jward CASCADE CONSTRAINTS; Cualquier constraints de llave foranea actualmente definido que use el privilegio revocado REFERENCES es borrado con la cláusula CASCADE CONSTRAINTS.

Efecto cascada de Revocar Privilegios Dependiendo del tipo de privilegio, quizás haya efectos de cascada cuando un privilegio es revocado. Privilegios de Sistema No hay efectos de cascada cuando se revoca un privilegio de sistema relative a operaciones DDL, sin importar que el privilegio haya sido otorgado con o sin la opción ADMIN OPTION. Por ejemplo, asumiendo que: 1. El administrador de seguridad otorga el privilegio CREATE TABLE al usuario jfee con la opción ADMIN OPTION. 2. jfee crea una tabla. 3. jfee otorga el privilegio CREATE TABLE al usuario tsmith. 4. tsmith crea una tabla. 5. El administrador de seguridad revoca el privilegio CREATE TABLE del usuario jfee. 6. La tabla del usuario jfee continua existiendo. Tsmith todavía tiene la tabla y el privilegio CREATE TABLE. Los efectos de cascada se pueden observar cuando se revoca un privilegio de sistema relativa a una operación DML. Si el privilegio SELECT ANY TABLE se revoca de un usuario, entonces todos los procedimientos contenidos en el esquema relativo a este privilegio va a fallar hasta que el privilegio sea reotorgado.

Ver información de Privilegios y Roles Para acceder a información sobre privilegios y roles otorgados, se puede consultar las vistas de los ejemplos a continuación. Algunos ejemplos asumen que se han realizado las siguientes sentencias: CREATE ROLE security_admin IDENTIFIED BY s3gur1dad; GRANT CREATE PROFILE, ALTER PROFILE, DROP PROFILE, CREATE ROLE, DROP ANY ROLE, GRANT ANY ROLE, AUDIT ANY, AUDIT SYSTEM, CREATE USER, BECOME USER, ALTER USER, DROP USER TO security_admin WITH ADMIN OPTION; GRANT SELECT, DELETE ON SYS.AUD$ TO security_admin; GRANT security_admin, CREATE SESSION TO swilliams; GRANT security_admin TO system_administrator; GRANT CREATE SESSION TO jward; GRANT SELECT, DELETE ON emp TO jward; GRANT INSERT (ename, job) ON emp TO swilliams, jward;

Listar todos los Privilegios Otorgados La siguiente consulta muestra todos los privilegios de sistema hechos a usuarios y roles: SELECT * FROM DBA_SYS_PRIVS; GRANTEE PRIVILEGE ADM SECURITY_ADMIN ALTER PROFILE YES SECURITY_ADMIN ALTER USER YES SECURITY_ADMIN AUDIT ANY YES SECURITY_ADMIN AUDIT SYSTEM YES SECURITY_ADMIN BECOME USER YES SECURITY_ADMIN CREATE PROFILE YES SECURITY_ADMIN CREATE ROLE YES SECURITY_ADMIN CREATE USER YES SECURITY_ADMIN DROP ANY ROLE YES SECURITY_ADMIN DROP PROFILE YES SECURITY_ADMIN DROP USER YES SECURITY_ADMIN GRANT ANY ROLE YES SWILLIAMS CREATE SESSION NO JWARD CREATE SESSION NO

Listar todos los roles otorgados La siguiente consulta retorna todos los roles otorgados a usuarios y otros roles: SELECT * FROM DBA_ROLE_PRIVS; GRANTEE GRANTED_ROLE ADM SWILLIAMS SECURITY_ADMIN NO Listar privilegios de objeto otorgados a usuarios La siguiente consulta retorna todos los privilegios de objeto (sin incluir a los privilegios de columnas específicas) otorgados a un usuario específico: SELECT TABLE_NAME, PRIVILEGE, GRANTABLE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'JWARD'; TABLE_NAME PRIVILEGE GRANTABLE EMP SELECT NO EMP DELETE NO

Para listar todos los privilegios de columnas especificas que han sido otorgados, usar la siguiente consulta: SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE FROM DBA_COL_PRIVS; GRANTEE TABLE_NAME COLUMN_NAME PRIVILEGE SWILLIAMS EMP ENAME INSERT SWILLIAMS EMP JOB INSERT JWARD EMP NAME INSERT JWARD EMP JOB INSERT Listar los privilegios actuales de su sesión La siguiente consulta lista todos los roles que están habilitados para la sesión: SELECT * FROM SESSION_ROLES; Si el usuario swilliams tiene habilitado el rol security_admin y ejecuta esta consulta, Oracle retorna la siguiente información: ROLE SECURITY_ADMIN

La siguiente consulta muestra todos los privilegios de sistema que están disponibles para la sesión, ambos desde privilegio explicito otorgado y roles habilitados: SELECT * FROM SESSION_PRIVS; PRIVILEGE AUDIT SYSTEM CREATE SESSION CREATE USER BECOME USER ALTER USER DROP USER CREATE ROLE DROP ANY ROLE GRANT ANY ROLE AUDIT ANY CREATE PROFILE ALTER PROFILE DROP PROFILE Si el rol security_admin esta deshabilitado para swilliams, la primera consulta no mostrara ningún resultado, mientras que la segunda consulta solo mostrara una fila para el privilegio otorgado de CREATE SESSION.

Listar Roles de la Base de Datos Los roles del diccionario de datos DBA_ROLES puede ser usado para listar todos los roles de una base de datos y la autenticación usada por cada rol. Por ejemplo, la siguiente consulta lista todos los roles en la base de datos: SELECT * FROM DBA_ROLES; ROLE PASSWORD CONNECT NO RESOURCE NO DBA NO SECURITY_ADMIN YES Listar información acerca de los dominios de Privilegios y Roles Las vistas de diccionarios de datos ROLE_ROLE_PRIVS, ROLE_SYS_PRIVS, y ROLE_TAB_PRIVS contienen información sobre los dominios de privilegios de roles. Por ejemplo, la siguiente consulta lista todos los roles otorgados al rol system_admin: SELECT GRANTED_ROLE, ADMIN_OPTION FROM ROLE_ROLE_PRIVS WHERE ROLE = 'SYSTEM_ADMIN'; GRANTED_ROLE ADM SECURITY_ADMIN NO

La siguiente consulta lista todos los privilegios de sistema otorgados al rol security_admin: SELECT * FROM ROLE_SYS_PRIVS WHERE ROLE = 'SECURITY_ADMIN'; ROLE PRIVILEGE ADM SECURITY_ADMIN ALTER PROFILE YES SECURITY_ADMIN ALTER USER YES SECURITY_ADMIN AUDIT ANY YES SECURITY_ADMIN AUDIT SYSTEM YES SECURITY_ADMIN BECOME USER YES SECURITY_ADMIN CREATE PROFILE YES SECURITY_ADMIN CREATE ROLE YES SECURITY_ADMIN CREATE USER YES SECURITY_ADMIN DROP ANY ROLE YES SECURITY_ADMIN DROP PROFILE YES SECURITY_ADMIN DROP USER YES SECURITY_ADMIN GRANT ANY ROLE YES La siguiente consulta lista todos los privilegios de objetos otorgados al rol security_admin: SELECT TABLE_NAME, PRIVILEGE FROM ROLE_TAB_PRIVS WHERE ROLE = 'SECURITY_ADMIN'; TABLE_NAME PRIVILEGE AUD$ DELETE AUD$ SELECT

ORACLE DBA ADMINISTRACION DE BASE DE DATOS

Presentaciones similares

Presentación del tema: "ORACLE DBA ADMINISTRACION DE BASE DE DATOS"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

ORACLE DBA ADMINISTRACION DE BASE DE DATOS

Presentaciones similares

Presentación del tema: "ORACLE DBA ADMINISTRACION DE BASE DE DATOS"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback