Objetivos de Certificación
1. Creando y gestionando Cuentas de Usuarios de Base de Datos.
2. Otorgar y Revocar Privilegios. (Grant - Revoke).
3. Crear y Gestionar Roles.
4. Crear y Gestionar Perfiles. (Profiles).
Cuando un Usuario se registra (inicio de sesión) en la Base de Datos, siguiendo algunos medios de identificación se conecta a una cuenta de usuario. La cuenta de usuario define permisos de acceso inicial y los atributos de la sesión. Asociado con una Cuenta de Usuario esta un Esquema. Los términos “Usuario”, “Cuenta de usuario” y “Esquema” pueden a menudo ser usados alternativamente en el Ambiente de Oracle, pero no son siempre lo mismo. Un usuario es una persona que se conecta a una cuenta de usuario para establecer una sesión contra la instancia y el registro con el nombre de cuenta de usuario. Un esquema es un conjunto de objetos propios de una cuenta de usuario, y es descrito en el Capitulo 9.
Hay muchas instalaciones (facilidades) para hacer cumplir la seguridad dentro de una Base de Datos Oracle. Este capítulo trata con aquellos relacionados con las cuentas de usuario-algunos otros son tratados en el capítulo 12. Una cuenta de usuario se debe conceder privilegios antes de una sesión (o sesiones) conectado con la cuenta puede hacer cualquier cosa. Hay muchos diferentes privilegios que pueden ser concedidos para muchos objetos y acciones, y la gestión de privilegios individual no es práctico para alguno pero los sistemas más simples. Los privilegios son generalmente agrupados en roles, que hacen que la administración de privilegios mucho más fácil.
Por último, este capítulo se examina perfiles. Los perfiles se pueden utilizar para administrar las contraseñas y (en cierta medida) el control de los recursos que un usuario se le permite tomar posesión en la instancia y la base de datos.
OBJETIVO DE CERTIFICACION 8.01.
CREAR Y GESTIONAR CUENTAS DE USUARIO DE BASE DE DATOS.
Para establecer una sesión contra una Instancia y una Base de Datos, un usuario debe conectarse a una cuenta de usuario. La cuenta debe ser especificada por su nombre y autentificada por algún medio. La manera que la cuenta fue creada fijara un rango de atributos para la sesión, algunos de los cuales puede ser cambiado posteriormente mientras la sesión está en curso. Existe una serie de cuentas creadas en el momento de creación de la Base de Datos y el DBA generalmente creara muchas más posteriormente.
En algunas aplicaciones, cada usuario tendrá su propia cuenta de usuario de Base de Datos. Esto significa que la Base de Datos es plenamente consciente a quien pertenece cada sesión realmente. Este modelo de seguridad funciona bien para pequeñas aplicaciones pero es a menudo impráctico para grandes sistemas con muchas cientos o miles de usuarios. Para grandes sistemas, muchos usuarios se conectarán con la misma cuenta de usuario. Este modelo se basa en la aplicación para asignar el usuario final real a una cuenta de usuario de Base de Datos, y se puede hacer de la seguridad a nivel usuario y auditoria más complejo. Este capítulo se asume que conocen a cada usuario a la Base de Datos; todos ellos tienen su propia cuenta de usuario.
ATRIBUTOS DE LAS CUENTAS DE USUARIO.
Una cuenta de usuario tiene una serie de atributos definido en la cuenta en tiempo de creación. Estos serán aplicados a las sesiones que se conectan a la cuenta, aunque algunos puede ser modificados por la sesión o el DBA mientras la sesión esta ejecutándose, estos atributos son:
• Username.
• Authentication Method.
• Default Tablespace.
• Tablespace Quotas.
• Temporary Tablespace.
• User profile.
• Account Status.
Todos esto debe ser especificado al crear el usuario, aunque sólo nombre de usuario y métodos de autenticación son obligatorios, los demás tienen valores por defecto.
USERNAME
El username debe ser único en la Base de Datos y debe ajustarse por ciertas reglas. Un username debe iniciar con una Letra, debe ser no más de 30 caracteres, y consiste de solo letras, dígitos y el carácter dólar ($) y guion bajo (_). Un username no puede ser una palabra reservada. Las letras son case sensitive pero serán convertidas automáticamente a mayúsculas. Todas estas reglas (con la excepción de la longitud) puede ser evadidas sin el username es especificado dentro de comillas dobles, como lo muestra en la Figura 8-1.
En el primer ejemplo de la figura, un username JOHN es creado. Este fue ingresado en minúsculas, pero se han convertido a mayúsculas, como puede verse en la primera consulta. El segundo ejemplo utiliza doble comillas para crear el usuario con un nombre en minúsculas. El tercer y cuarto ejemplo utilizada doble comillas para eludir las reglas en caracteres y palabras reservadas; ambos fallarían sin las comillas dobles. Si un username incluye letras en minúsculas o caracteres no validos o una palabra reservada, entonces las comillas dobles deben ser siempre utilizadas para conectarse a la cuenta posteriormente.
EN EL TRABAJO
Es posible el uso de usernames no estándares, es esto puede causar confusión terrible. Algunas aplicaciones se basan en la conversión del caso; otras siempre utilizan comillas dobles. Puede ser considerado buena práctica siempre usar mayúsculas y solo caracteres estándar. Esto significa que comillas dobles puede ser utilizadas o no.
Un username nunca puede ser cambiado después de su creación. Si es necesario cambiarlo, la cuenta debe ser eliminada y otra cuenta creada. Esta es una acción drástica, porque todos los objetos en el esquema del usuario serán eliminados con el usuario.
TABLESPACE DEFAULT Y QUOTAS.
Cada cuenta de usuario tiene un Tablespace por defecto, este es el Tablespace donde todos los objetos de esquema (como tablas o índices) creados por el usuario residirán. Es posible para un usuario tener objetos propios en cualquier Tablespaces en el cual ha sido dada una Quota. Pero a menos que otro Tablespace se especifique cuando se crea el objeto, entrara en Tablespace por defecto del usuario.
Hay un Tablespace por default de Base de Datos grande que será aplicado a todas las cuentas de usuario si un Tablespace default no se especifica cuando se crea el usuario. El valor por defecto puede ser establecido cuando se crea la Base de Datos y cambiarlo posteriormente con.ALTER DATABASE DEFAULT TABLESPACE tablespace_name ;
FIGURE 8-1
Si un Tablespace por defecto no es especificado cuando se crea la Base de Datos, se establecerá el Tablespace SYSTEM.
EN EL TRABAJO
Despues de crear una Base de Datos, no deje el Tablespace SYSTEM por default; esto es muy mala práctica. O bien el cambio tan pronto como se haya creado otro Tablespace, o después del comando CREATE DATABASE de hecho le permite crear un Tablespace por defecto.
Una Quota es la cantidad de espacio en el Tablespace que un usuario está permitido a ocupar. El puede crear objetos y asignar extents a los mismos hasta que la cuota es alcanzada. Si él no tiene una Quota en un Tablespace, el no puede crear objetos en los absoluto. Las Quotas pueden ser cambiadas en cualquier momento. Si la Quota de un usuario es reducida por debajo del tamaño de los objetos que ya posee (o incluso reducida a cero), los objetos sobrevivirán y todavía serán utilizables, pero no se le permitirá hacerse más grandes.
La figura 8-2 muestra como investigar y establecer Quotas.
La primera consulta en la figura es contra DBA_USERS y determina los Tablespace default y temporal para el usuario JOHN, creado en la figura 8-1. DBA_USERS tiene una fila por cada cuenta de usuario en la Base de Datos. El usuario JHON ha cogido los default de la Base de Datos para default y temporal Tablespaces, que se muestran en la última consulta contra DATABASE_PROPERTIES.
EXAMEN
Antes de crear una Tabla, usted debe tener permiso para ejecutar CREATE TABLE y una Quota en un Tablespace en la que puede crearlo.
El dos comandos ALTER USER en la figura 8-2, da a JOHN la capacidad para tomar 10 MB de espacio en el Tablespace USERS y una cantidad ilimitada de espacio en el Tablespace EXAMPLE. La consulta contra DBA_TS_QUOTAS confirma esto la figura “-1” es la forma “ilimitada” está representado. En el momento de la consulta se ejecuto JOHN no tenia creado ningún objeto, por lo que las cifras bytes son ceros, lo que indica que el no está utilizando espacio en ese Tablespace.
EN EL TRABAJO
La mayoría de usuarios no necesitarán las Quotas, porque ellos nunca crearán objetos. Tendrán solamente permisos contra los objetos poseídos por otros esquemas. Los pocos esquemas de objetos poseídos probablemente tendrán QUOTA UNLIMITED en los Tablespaces donde residen sus objetos.
TABLESPACE TEMPORALES.
Objetos permanentes son almacenados en Tablespaces permanentes, objetos temporales son almacenados en Tablespace temporales. Una sesión necesitara espacio en un Tablespace temporal, si necesita espacio para ciertas operaciones que exceden el espacio disponible en la PGA de la sesión. Recuerde que la PGA es la Program Global Area, la memoria privada a la sesión. Operaciones que necesitan espacio temporal (en memorial si es posible, en un Tablespace temporal si es necesario) incluye ordenación de filas, unión de tablas, construcción de índices y utilización de tablas temporales. Cada cuenta de usuario es asignada a un Tablespace temporal, y todas las sesiones de usuario conectadas a la cuenta compartirán este Tablespace temporal.
La consulta contra DBA_USERS en la figura 8-2 muestra el Tablespace temporal del usuario JOHN, que es el Tablespace Temporal default de la Base de Datos. Esto es mostrado por la última consulta en la figura 8-2, contra DATABASE_PROPERTIES.
Objetos temporales son creados y eliminados según sea necesario por la Base de Datos. Un usuario no es necesario otorgar una cuota en un Tablespace Temporal. Esto es porque los objetos no son en realidad propiedad de él, sino son propiedad del usuario SYS, que tiene una cuota limitada en todos los Tablespaces.
EXAMEN
Los usuarios no necesitan una cuota en sus Tablespace temporal.
Para cambiar el Tablespace Temporal de un usuario (que afectara a todas las futuras sesiones que se conecten a la cuenta), utilice el comando ALTER USER:
ALTER USER username TEMPORARY TABLESPACE tablespace_name;
EN EL TRABAJO
Si muchos usuarios se conectan a la misma cuenta de usuario, ellos compartirán el uso de un Tablespace temporal. Esto puede ser un cuello de botella de rendimiento, que puede evitarse mediante el uso de grupos de Tablespaces temporales.
PERFILES (PROFILE)
Un perfil de usuario controla su configuración de la contraseña y le da una cantidad limitada de control sobre su uso de recursos. El uso de perfiles es detallado en la sección Create y Gestionar Perfiles.
Los perfiles son una manera útil de gestionar Passwords y recursos, pero en realidad solo puede aplicarse en un entorno donde cada usuario de aplicación tiene su propia cuenta de usuario de base de datos. Por ejemplo, si muchos usuarios conectados a la misma cuenta de usuario de base de datos, usted no desea que la contraseña sea invalidado para uno de ellos, porque eso bloquearía todos los demás. Similarmente, el uso de los recursos a menudo necesita ser gestionados en función de cada sesión en lugar de para la cuenta en total.
ESTADO DE LA CUENTA.
Cada cuenta de usuario tiene un cierto estatus, como se indica en la colunma ACCOUNT_STATUS de DBA_USERS. Estos son nueve posibles:
• OPEN la cuenta está disponible para su uso.
• LOCKED esto indica que el DBA deliberadamente bloqueo la cuenta. El usuario no puede conectarse a una cuenta bloqueada.
• EXPIRED esto indica que el tiempo de visa ha caducado. Los Password pueden tener un tiempo de vida limitado. Ningún usuario puede conectarse a una cuenta EXPIRED hasta que el Password sea reseteado.
• EXPIRED & LOCKED no solo ha sido bloqueada la cuenta, pero su contraseña también ha expirado.
• EXPIRED (GRACE) esto indica que el periodo de gracia está en vigor. Un Password no necesita expirar inmediatamente cuando su curso de vida termina; puede ser configurado con un periodo de gracia durante el cual los usuarios pueden conectarse a la cuenta de tener oportunidad para cambiar el Password.
• LOCKED (TIMED) esto indica que la cuenta está bloqueada porque el numero de intentos de Login fallo. Una cuenta puede ser configurada para bloquearse automáticamente por un periodo después de una Password incorrecto se presenta un número determinado de veces.
• EXPIRED & LOCKED (TIMED)
• EXPIRED (GRACE) & LOCKED
• EXPIRED (GRACE) & LOCKED (TIMED)
Para bloquear y desbloquear una cuenta, utilice estos comandos:
ALTER USER username ACCOUNT LOCK ;
ALTER USER username ACCOUNT UNLOCK ;
Para obligar al usuario a cambiar su Password, utilice este comando:
ALTER USER username PASSWORD EXPIRE;
Esto inmediatamente iniciara el periodo de gracia, obligando al usuario a cambiar su password en el siguiente intento de Login. No hay comando como “alter … unexpire”. La única manera de hacer la cuenta es totalmente funcional otra vez para restablecer su contraseña;
METODOS DE AUTENTIFICACION
Una cuenta de usuario debe tener un método de autentificación: algún medio por el cual la Base de Datos pueda determinar su el usuario intenta crear una sesión conectándose a la cuenta se le permite hacerlo. La técnica más sencilla es mediante la presentación de una contraseña que será comparada contra una contraseña almacenada dentro de la Base de Datos, pero hay alternativas. Las posibilidades son:
• Operating System Authentication.
• Password File Authentication.
• Password Authetication.
• External Authentication.
• Global Authentication.
Las primeras dos técnicas son utilizadas solo por administradores; las ultimas requieren un Servidor de Directorio LDAP. El servidor de directorio LDAP es el Oracle Internet Directory, enviadas como parte de Oracle Application Server.
OPERATING SYSTEM AND PASSWORD FILE AUTHENTICATION
Para habilitar autentificación de Sistema Operativo y Archivo de Password (los dos van juntos) para una cuenta, usted debe otorgar al usuario o SYSDBA o el privilegio SYSOPER:
GRANT [sysdba | sysoper ] TO username ;
La concesión de uno o ambos de estos privilegios copiara el Password de usuario del Diccionario de Datos en el archivo externo de Password. Donde este puede ser leído mediante la instancia incluso si la Base de Datos no está abierta. También permite que la instancia autentifique a usuario comprobando si el usuario del sistema operativo es un miembro del grupo de sistema operativo que posee la instalación de Oracle Home.
Después de la creación de la Base de Datos, el único usuario con estos privilegios s SYS.
Para utilizar la autentificación de archivo de Password, el usuario puede conectarse con esta sintaxis con SQL PLUS.
CONNECT username / password [@db_alias] AS [ SYSOPER | SYSDBA ] ;
Tenga en cuenta que la autentificación de archive de password puede ser utilizada para una conexion a una Base de Datos Remota sobre Oracle Net.
Para utilizar la autentificación de sistema operativo, el usuario puede conectarse con esta sintaxis con SQL PLUS:
CONNECT / AS [ SYSOPER | SYSDBA ] ;
El Password de sistema operativo no es almacenado por Oracle, y por lo tanto no hay ediciones con contraseñas cambiantes.
El equivalente de estas sintaxis está disponible cuando se conecta con el Database Control, mediante la selección de SYSDBA desde la conexión en la lista desplegable en la ventana de Logindel Database Control. Para determinar a quien el rpivilegio SYSDBA y el SYSOPER se han concedido, consulte la vista V$PWFILE_USERS. La conexión con la autentificación de sistema operativo o archivo de Password siempre es posible, no importa en qué estado la Instancia y Base de Datos se encuentren, y es necesario para emitir comandos STARTUP o SHUTDOWN. Un privilegio tercero que opera de la misma manera como SYSDBA y SYSOPER es SYSASM. Este es un privilegio que sólo es aplicable a los casos de ASM.
EXAMEN
Todas las sesiones de usuario debe ser autenticado. No hay tal cosa como un "anónimo" de inicio de sesión, y algún método de autenticación se debe utilizar.
PASSWORD AUTHENTICATION
La sintaxis para una conexión con autentificación Password utilizando SQL PLUS es
CONNECT username / password [@db_alias] ;
O con Database Control, selección NORMAL de la lista desplegable.
Cuando se conecta con autentificación de Password, la instancia validara el Password dada contra esa que esta almacenada con la cuenta de usuario en el diccionario de datos. Para que esto funcione, la Base de datos debe estar abierta; es lógicamente imposible emitir un comando STARUP o SHUTDOWN cuando se conecta con autentificación Password. El usuario SYS no está permitido para conectarse con la autentificación Password; solo autentificación Archivo de contraseñas, sistema operativo o autentificación LDAP como posibles para SYS.
Los nombres de usuario distinguen entre mayúsculas y minúsculas, pero son convertidos automáticamente a mayúsculas a menos que especifique con comillas dobles. En versiones previas de la Base de Datos, Los Passwords no distinguían mayúsculas y minúsculas en lo absoluto. Con la versión 11g, los Passwords son sensibles a mayúsculas y no hay ningún caso de conversión automática. No es necesario el uso de comillas dobles; el Password siempre será leído exactamente como se escribió.
Cuando una conexión es realizada atraves de una red, la versión 11g siempre encriptara utilizando el algoritmo AES antes de su transmisión. Para utilizar encriptamiento para el tráfico en curso entre procesos usuarios y procesos servidor requiere la opción de Seguridad Avanzada, pero el encriptamiento de Password es un estándar.
Cualquier usuario puede cambiar su Password de su cuenta de usuario en cualquier momento, o un usuario con muchos privilegios (tal como SYSTEM) puede cambiar cualquier Password de la cuenta de usuario. La sintaxis (si va a cambiar su propia contraseña u otro) es:
ALTER USER username IDENTIFIED BY password ;
Si su cuenta de usuario es creada con autentificación externa, Oracle delegara la autentificación a un Servicio Externo; no le pedirá una contraseña. Si la opción de Seguridad Avanzada ha sido licenciada, entonces el servicio externo puede ser un Servidor Kerberos, un Servidor Raduis, o el servicio nativo de autentificación (en el entorno Windows) de Windows. Cuando un usuario intenta una conexión a la cuenta de usuario, en lugar de la autentificación del mismo usuario, la instancia de Base de Datos aceptara o rechazara la autentificación en función a si el servicio externo de autentificación autentifico al usuario. Por ejemplo, si utilizas Kerberos, la Base de datos comprobara que el usuario tiene un token valido de Kerberos.
Sin la opción de seguridad avanzada, la única forma para autentificación externa puede ser utilizando la autentificación del sistema operativo. Esto es un requerimiento para la cuentas SUSDBA y SYSOPER (como ya hemos comentado) pero puede también ser utilizado por usuarios normales.
La técnica es crear una cuenta de usuario Oracle con el mismo nombre como la cuenta de usuario de sistema operativo pero procedido con una cadena especificada por el parámetro de instancia OS_AUTHENT_PREFIX. Este valor predeterminado de parámetro a la cadena OPS$. Para comprobar su valor, utiliza la consulta tal como esta:
select value from v$parameter where name='os_authent_prefix';
Sobre Linux o Unix, autentificación externa con sistema operativo es muy simple. Suponiendo que el OS_AUTHENT_PREFIX está predeterminado y que hay un usuario del sistema operativo llamado jwatson, entonces crear un usuario Oracle y otorgar el privilegio de crear sesión:
create user ops$jwatson identified externally;
grant create session to ops$jwatson;
Cualquier usuario Logeado sobre Unix como jwatson será capaz de emitir este comando:
sqlplus /
Desde un prompt de sistema operativo, será conectado a la Base de Datos con la cuenta de usuario ops$jwatson. Debajo de Windows, cuando Oracle consulta el sistema operativo para encontrar la identidad del usuarios, Windows Usualmente regresa (depending on details of Windows security configuration) el nombre de usuario prefijado con el Dominio Windows. Suponiendo que el Id de inicio de sesión de Windows es John Watson (incluyendo un espacio) y que el dominio es JWACER (que pasa a ser el nombre de la maquina) y que el OS_AUTHENT_PREFIX es un valor por default, el comando será:
create user "OPS$JWACER\JOHN WATSON" identified externally;
Tenga en cuenta que el nombre de usuario deber en mayúsculas, y debido a los caracteres ilegales (una barra invertida y un espacio) debe ir entre comillas dobles.
EN EL TRABAJO
Utilizar autentificación externa puede ser muy útil, pero solo si el usuario realmente inicia sesión en la maquina host de la Base de Datos. Los usuarios rara vez lo hará, por lo que la técnica es más probable que sea de valor para las cuentas utilizadas para ejecutar trabajos de mantenimiento o por lotes.
AUTENTIFICACION GLOBAL
Un nuevo estándar para la gestión de identidad es el uso de servidores LDAP. Un directorio compatible con un servidor LDAP, el Oracle Internet Directory, es distribuido por Oracle Corporation como parte del Servidor de aplicaciones Oracle. Un usuario global es un usuario que se define en el directorio LDAP y autentificación global es una forma de delegar la autentificación de usuarios en el directorio.
Hay dos técnicas para autentificación global:
• Los usuarios pueden ser definidos en el directorio, y también en la Base de Datos. Un usuario se conecta a una cuenta de usuario con el mismo nombre que el nombre común del usuario en el directorio.
• Los usuarios pueden ser definidos solo en el directorio. La base de datos se dará cuenta de los nombres de los usuarios globales, pero se conecta a todos los usuarios a la misma cuenta de usuario.
Ninguna de estas técnicas requiere que el usuario presente una contraseña para la base de datos. La conexión va a pasar sin ningún mensaje si las cuentas de la guía y las cuentas de usuario de base de datos están configuradas correctamente.
CREANDO CUENTAS.
El comando CREATE USER solo tiene dos argumentos necesarios: un nombre de usuario y un método de autentificación. Opcionalmente. Puede aceptar una clausula para especificar un Tablespace por default y un Tablespace temporal. Una o más clausulas de Quota, un nombre de perfil, y comandos para bloquear la cuentas y caducar el Password. Un típico ejemplo sería.
1 create user scott identified by tiger
2 default tablespace users temporary tablespace temp
3 quota 100m on users, quota unlimited on example
4 profile developer_profile
5 password expire
6 account unlock;
Solo la primera línea es requerida, hay valores por default para todos lo demás. Tomando el comando línea por línea.
1. Proporciona el username, y una contraseña para autentificación con contraseña.
2. Proporciona los Tablespaces Default y Temporal.
3. Establece Quotas sobre el Tablespace Default y otros.
4. Designa un Perfil para contraseña y gestión de recursos.
5. Obliga al usuario cambiar su Password inmediatamente.
6. Hace la cuenta disponible para usarla (que habría sido el valor por default.).
Cualquier atributo de una cuenta puede ser modificado posteriormente con el comando ALTER USER. Con la excepción del nombre. Para cambiar el Password,
alter user scott identified by lion;
Para cambiar los Tablespaces Default y temporal.
alter user scott default tablespace hr_data temporary tablespace hr_temp;
Para cambiar Quotas.
alter user scott quota unlimited on hr_data, quota 0 on users;
Para cambiar el Perfil.
alter user scott profile prod_profile;
Para obligar cambiar su password,
alter user scott password expire;
Para bloquear la cuenta,
alter user scott account lock;
Teniendo creada una cuenta de usuario, puede ser necesario eliminarla.
drop user scott;
Este comando únicamente funcionará si el usuario no posee ningún objeto: si el esquema esta vacio. Si usted no quiere identificar todos los objetos propios y eliminarlos primero, puede eliminarlos con el usuario pero especificando CASCADE:
drop user scott cascade;
Para gestionar las cuentas con el Database Control, desde la pagina principal del Database Control tome la ficha Schema y luego el Link Users en la sección de seguridad. Esto mostrará las cuentas de usuario en la Base de Datos. La figura 8-3 las muestra ordenadas en orden inverso de su fecha de creación. Para cambiar el orden haga clic en el encabezado de la columna correspondiente.
El primer “usuario” es la imagen es el PUBLIC. Este es un usuario ficticio a quien los privilegios pueden ser otorgados si usted desea concederlos a cada usuario. El botón Crear presentará una ventana solicitando todos los atributos de la cuenta de usuario. El botón Delete eliminará una cuenta, con la opción CASCADE si es necesario. Pero le dará un “Estas seguro de” antes de proceder.
Para modificar los atributos de una cuenta, seleccione y dar clic en Edit. Esto lo llevará a la ventana Editar Usuario. Como lo muestra la figura 8-4. Esta ventana puede ser utilizado para cambiar todos los aspectos de la cuenta excepto para Quotas de Privilegios, que tienen sus propias fichas. También cuenta con etiquetas para Grant y Revoking privilegios y roles.
EJERCICIO 8-1.
CREAR USUARIOS.
En este ejercicio, usted creara algunos usuarios para ser utilizados por los ejercicios restantes en este capítulo. Se asume que hay un Tablespace permanente llamado EXAMPLE y un Tablespace temporal llamado TEMP. Si estos no existen, o crearlos o utilizar cualquier Tablespace adecuado.
1. Conéctese a su Base de Datos con SQL*PLUS como un usuario de privilegios altos, tales como SYSTEM o SYS.
2. Crear tres usuarios:
create user alois identified by alois
default tablespace example password expire;
create user afra identified by oracle;
default tablespace example quota unlimited on example;
create user anja identified by oracle;
3. Confirme que los usuarios han sido creados con el Database Control. Desde la página principal de la Base de Datos, la ruta de navegación es la Ficha Server y el link Users en la sección Security. Que debe ser parecido a los que se muestran en esta ilustración:
4. Desde el SQL*PLUS, intente conectarse como usuario ALOIS:
connect alois/alois
5. Cuando se le solicite, seleccione un nuevo Password (tales como “oracle”). Pero no va a servir de algo, porque ALOIS no tiene el rpivilegio CREATE SESSION.
6. Refrescar la ventana del Database Control, y note el status de la cuenta ALOIS ya no es EXPIRED pero abierto, porque su contraseña ha cambiado.
OBJETIVO DE CERTIFICACION 8.02.
CONCEDER Y REVOCAR PRIVILEGIOS
Por default, nadie puede hacer nada en una Base de Datos Oracle. Como usuario no puede incluso conectarse sin el otorgamiento de un privilegio. Y una vez hecho esto, todavía no puede hacer nada útil (o peligroso) sin haber dado más privilegios. Los privilegios son asignados a las cuentas de usuarios con el comando GRANT y retirados con un REVOKE. Sintaxis adicional puede dar a usuario capacidad para conceder privilegios a otros usuarios. Por defecto sol el DBA (SYS y SYSTEM) tiene el derecho para conceder
Los privilegios vienen en dos grupos: Privilegios de sistemas que (generalmente hablando) permite a a los usuarios desarrollar acciones que afecten el diccionario de datos y privilegios de objeto que permiten a los usuarios desarrollar acciones que afectan los datos.
PRIVILEGIOS DE SISTEMA.
Hay cerca de dos cientos privilegios de sistema. La mayoría aplica para acciones que afectan el diccionario de datos, tales como creación de tablas o usuarios. Otros afectan la Base de Datos o la Instancia, tales como creación de Tablespaces, modificar valores de los parámetros de instancia, o el establecimiento de una sesión. Algunos de los más comúnmente utilizados son:
• CREATE SESSION este permite a los usuarios conectarse, sin este, no puede incluso loguearse en la Base de Datos.
• RESTRICTED SESSION si la Base de Datos es iniciada con STARTUP RESTRICT, o modificada con ALTER SYSTEM ENABLE RESTRICTED SESSION, solo los usuarios con este privilegio serán capaz de conectarse.
• ALTER DATABASE da acceso a muchos comandos necesarios para modificar estructuras físicas.
• ALTER SYSTEM Da control total sobre parámetros de instancia y estructuras de memoria.
• CREATE TABLESPACE con los privilegios ALTER TABLESPACE y DROP TABLESPACE, este permitirá a los usuarios gestionar Tablespaces.
• CREATE TABLE permite al concesionario crear tablas en su propio esquema; incluso la capacidad para alterar y eliminarlos, para ejecutar SELECT y comandos DML sobre ellos, y para crear, alterar o eliminar índices sobre ellos.
• GRANT ANY OBJECT PRIVILEGE permite al concesionario conceder permisos de objetos sobre objetos que él no posee a otros pero no para si misma.
• CREATE ANY TACLE el concecionario puede crear tablas que pertenecen a otros usuarios.
• DROP ANY TABLE. El concesionario puede eliminar tablas pertenecientes a otros usuarios.
• INSERT ANY TABLE, UPDATE ANY TABLE, DELETE ANY TABLE el concesionario puede ejecutar estos commandos DML contra tablas propiedad de todos los demas usuarios.
• SELECT ANY TABLE el concesionarios puede SELECT cualquier tabla en la Base de Datos.
GRANT privilege [, privilege...] TO username ;
Despues de crear una cuenta de usuario, un comando tal como este otorgará los privilegios de sistema comúnmente asignado a usuario que estarán involucrados en el desarrollo de aplicaciones:
grant create session, alter session,
create table, create view, create synonym, create cluster,
create database link, create sequence,
create trigger, create type, create procedure, create operator
to username ;
Estos privilegios le permiten al usuario conectarse y configurar su sesión, y entonces crear objetos para almacenar datos y objetos PL/SQL. Estos objetos solo pueden existir en su propio esquema; no tendrá privilegios contra cualquier otro esquema. La creación de objetos también se verá limitada por la cuota puede haber sido asignado en varios Tablespaces.
Una variación en la sintaxis le permite pasar sus privilegios a otros terceros. Por ejemplo:
connect system/oracle;
grant create table to scott with admin option;
connect scott/tiger;
grant create table to jon;
Este da a SCOTT la capacidad para crear tablas en su propio esquema, y también para emitir el mismo el comando GRANT. En este ejemplo. Se le permite a JON crear tablas también. Pero JON solo será capaz para crear en su propio esquema. La figura 8-5 muestra el resultado de los otorgamientos según lo presentado por el Database Control. La misma información puede ser recogida por una consulta a la vista DBA_SYS_PRIVS.
EXAMEN
La revocación de unos privilegios de sistema no es en cascada (a diferencia de una revocación de privilegio de objeto)
Si un privilegio es revocado de un usuario, cualquier acción realizada que se realiza con ese privilegio (tales como crear tablas) permanecerá intacta. También, si ha sido otorgado y había utilizado el ADMIN OPTION, cualquier usuario a quien le paso el privilegio lo retendrá. Hay registro guardado del otorgante de un privilegio de sistema, por lo que no es posible un REVOKE en cascada.
La figura 8-6 ilustra esto. El privilegio ANY da permiso contra todos los objetos relevantes en la Base de Datos.
Por lo tanto, grant select any table to scott;
Permitirá a SCOTT consultar cualquier tabla en cualquier esquema en la Base de Datos. Es a menudo considerado mala práctica otorgar el privilegio ANY a cualquier otro usuario que el administrador de sistemas.
EN EL TRABAJO
En realidad, no es tan peligroso ahora como con versiones anteriores. Ya no se incluyen tablas en el esquema SYS, por lo que el diccionario de datos esta todavía protegido. Pero ANY debe ser utilizado con extrema precaución, ya que elimina toda la protección de las tablas de usuarios.
PRIVILEGIOS DE OBJETOS
Los privilegios de objeto dan la capacidad para realizar los comandos SELECT, INSERT, UPDATE y DELETE contra tabla y objetos relacionados, y para ejecutar objetos PL/SQL. Estos privilegios no existen para los objetos propios en el esquema del usuario.
Si un usuario tiene el privilegio de sistema CRETA TABLE, puede realizar operaciones SELECT y DML contra las tablas que el crea sin la necesidad de adicionar permisos.
EXAMEN
El privilegio ANY, que concede permisos contra objetos en cualquier cuenta de usuario en la Base de Datos, no es privilegio de objeto, son privilegios de sistemas.
Los privilegios de objetos aplicados a los diferentes tipos de objetos
La sintaxis es.
GRANT privilege ON schema.object TO username [WITH GRANT OPTION] ;
Por ejemplo:
grant select on hr.regions to scott;
Las variaciones incluyen el uso de ALL, que aplicará todos los permisos relevantes al tipo de objeto, y nombramiento de columnas particulares de vistas y tablas.
grant select on hr.employees to scott;
grant update (salary) on hr.employees to scott;
grant all on hr.regions to scott;
Este código permitirá a SCOTT consultar todas las columnas de la tabla HR EMPLOYEES pero solo escribir a una columna nominada, SALARY. Luego SCOTT da tolos los privilegios (SELECT y DML) de objeto sobre la tabla HR REGIONS. La figura 8-7 muestra el resultado de esto, como vista en el Database Control.
EN EL TRABAJO
Otorgar privilegios a nivel de columna es a menudo ser una mala práctica debido a la carga de trabajo masivo que involucra. Si es necesario restringir el acceso a algunas personas a ciertas columnas, creando una vista que muestra solo las columnas a menudo será buena alternativa.
Utilizando WITH GRANT OPTION (o con el Database Control, seleccionado el Check Box GRANT OPTION como se muestra en la figura 8-7) permite a un usuario pasar sus privilegios de objeto sobre un tercer usuario. Oracle mantiene un registro de quien otorgo privilegios de objeto a quien. Esto permite un REVOKE sobre un objeto en cascada para todos estos en la cadena. Considere esta secuencia de comandos:
connect hr/hr;
grant select on employees to scott with grant option;
connect scott/tiger;
grant select on hr.employees to jon with grant option;
conn jon/jon;
grant select on hr.employees to sue;
connect hr/hr;
revoke select on employees from scott;
En la conclusión de este comando, ni SCOTT ni JON ni SUE tiene el privilegio SELECT contra HR.EMPLOYEES.
EXAMEN
La revocación de un privilegio de objeto es en cascada (a diferencia de un privilegio de sistema)
EJERCICIO 8-2.
OTORGANDO PRIVILEGIOS DIRECTOS.
En este ejercicio, usted otorgará algunos privilegios a los usuarios creados en el ejercicio 8-1 y probar que funcionan.
1. Conéctese a su Base de Datos como usuario SYSTEM con SQL*PLUS.
2. Otorgue CREATE SESSION al usuario ALOIS:
grant create sessions to alois;
3. Abrir otra sesión SQL*PLUS, y conéctese como ALOIS. Esta vez, el Login tendrá éxito.
connect alois/oracle
4. Como ALOIS, intente crear una Tabla:
create table t1 (c1 date);
Esta fallara con el mensaje “ORA-01031: insufficient privileges”
5. En la sesión SYSTEM, otorgue a ALOIS el privilegio CREATE TABLE:
grant create table to alois;
6. En la sesión ALOIS, intente nuevamente:
create table t1 (c1 date);
Este fallará con el mensaje “ORA-01950: no privileges on Tablespace ‘EXAMPLE’.”
7. En la sesión de SYSTEM, dar a ALOIS una quota en el Tablespace EXAMPLE:
alter user alois quota 1m on example;
8. En la session ALOIS, intente nuevamente, esta vez, la creación tendrá éxito.
9. Como ALOIS, conceda privilegios de objeto sobre la nueva Tabla:
grant all on t1 to afra;
grant select on t1 to anja;
10. Conectese al Database Control como SYSTEM.
11. Confirme que los privilegios de objeto han sido otorgados.
La ruta de navegación desde la página principal del Database Control es: sobre la ficha Schema dar clic al link Table en la sección Database Objects. Ingrese ALOIS cono el esquema y T1 como la tabla y dar clic en el botón Go. En la lista de Accions, seleccione Objects Privileges. Como lo muestra la siguiente ilustración, ANJA solo tiene SELECT, pero AFRA tiene todo. Tenga en cuenta que la ventana también muestra por quien los privilegios fueron concedidos, y que ninguno de ellos fue concedido con WITH GRANT OPTION
12. Con el Database Control, confirme que privilegios tiene otorgado ALOIS. La ruta de navegación desde la pagina principal de la Base de Datos es: sobre la ficha Server dar clic al link Users en la sesión de Seguridad, seleccione el Radio Button para ALOIS, dar clic al View Botón. Usted vera que tiene dos privilegios de sistema (CREATE SESSION y CREATE TABLE)sin la opción ADMIN OPTION, un 1MB de quota en EXAMPLE y nada más.
13. Recupere la misma información mostrada en los pasos 11 y 12 con SQL*PLUS. Como SYSTEM ejecute esta consulta:
where owner='ALOIS' and table_name='T1';
select * from dba_sys_privs where grantee='ALOIS';
14. Revoque los privilegios concedidos a AFRA y ANJA:
revoke all on alois.t1 from afra;
revoke all on alois.t1 from anja;
Confirme las revocaciones mediante el primer query del paso 13.
OBJETIVO DE CERTIFICACION 8.03
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/oracleselect * 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/oraclegrant 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.sqlEn 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.
EJERCICIO 8-4.
CREAR Y UTILIZAR PERFILES.
En este ejercicio, crear, asignar, y comprobar un Perfil que obligará a un cierto Control de Password.
1. Conectarse a su Base de Datos con SQL*PLUS como usuario SYSTEM.
2. Crear un Perfil que se bloqueara las cuentas después de dos contraseñas incorrectas.
create profile two_wrong limit failed_login_attempts 2;
3. Asignar este Nuevo Perfil a ALOIS:
alter user alois profile two_wrong;
4. Deliberadamente ingrese una contraseña incorrecta para ALOIS unas pocas veces.
connect alois/wrongpassword
5. Como usuario SYSTEM, desbloque la cuenta ALOIS:
alter user alois account unlock;
6. Compruebe que ALOIS puede ahora conectarse:
connect alois/oracle
La siguiente ilustración muestre la secuencia de eventos.
7. Poner en orden para Eliminar el Perfil, Los Roles y los usuarios. Observe el uso del CASCADE al eliminar el Perfil para quitarlo de ALOIS, y en el comando DROP USER para eliminar su tabla también. Los Roles pueden ser eliminados incluso si se les ha asignado a los usuarios. Las privilegios otorgados sobre la Tabla serán revocados como la Tabla es Eliminada.
connect system/oracle
drop profile two_wrong cascade;
drop role usr_role;
drop role mgr_role;
drop user alois cascade;
drop user anja;
drop user afra;
RESUMEN DE CERTIFICACION.
Las cuentas de usuario definen los usuarios que pueden conectarse a la Base de Datos y se asocian con un esquema que almacena objetos propiedad de la cuenta. Privilegios deben ser otorgados a una cuenta (directamente o vía Roles) antes de que la cuenta se usable de cualquier manera. Los privilegios viene en dos formas: Privilegios del Sistema que controlan ciertas acciones dentro de la Base de Datos (típicamente, las acciones que cambios al Diccionario de Datos) y Privilegios de Objetos que controlan acceso a los Datos. Un Rol es un paquete de privilegios. A diferencia de un privilegio (que siempre es posible cuando se ha concedido), un Rol puede ser habilitado o deshabilitado dentro de una sesión. Los perfiles dan control sobre las contraseñas de las cuentas y uso de los recursos. Todas la cuentas de usuarios tiene un perfil, por defecto el perfil es llamado DEFAULT. El perfil DEFAULT se puede ajustar, y el cambio inmediatamente se aplicara a todos los usuarios con el perfil DEFAULT. O perfiles adicionales pueden ser creados y asignados explícitamente a ciertos usuarios.
DOS MINUTOS
Crear y Gestionar Cuentas de Usuarios de Base de Datos.
• Los usuarios se conectan a una cuenta de usuario, que está conectada a un Esquema.
• Todos los usuarios deben ser autenticados antes de que puedan conectarse.
• Un usuario debe tener una Quota en un Tablespace antes que pueda crear cualquier objeto.
• Un usuario que es dueño de los objetos no puede ser Eliminado, a menos con las palabra CASCADE.
Otorgando y Revocar Privilegios
• Por Default, un usuario no puede hacer nada, incluso no puede Log On.
• Los privilegios Directos son siempre habilitados.
• Una revocación de un Privilegio de Sistema no en cascada; una revocación de un privilegio de Objeto se.
Crear y Gestionar Roles.
• Los Roles no son Objetos de Esquema.
• Los Roles pueden contener ambos privilegios de sistema y de objeto, y otros roles.
• Un Rol puede ser habilitado o deshabilitado para una sesión.
Crear y Gestionar Perfiles.
• Los Perfiles pueden gestionar Passwords y limites de recursos.
• Los límites de Password se hacen cumplir; los límites de los recursos dependen de un parámetro de instancia.
• Cada usuario siempre tiene un Perfil, Por default el perfil es DEFAULT.
No hay comentarios:
Publicar un comentario