Seguridad Oracle 11g R2

ADMINISTRACIÓN DE ORACLE 11G
Administración de la seguridad a nivel de usuario
1
Carmen Soler Chorro - http://www.linkedin.com/in/casoch

INTRODUCCIÓN
 Los puntos que trataremos en este capítulo
serán:
 Cómo crear y gestionar cuentas de usuario de la
base de datos.
 Cómo conceder y revocar privilegios
 Cómo crear y gestionar roles de usuario
2

INTRODUCCIÓN
 Cuando nos logamos a la base de datos,
indicamos un usuario y un password de una
cuenta de usuario.
 Esta cuenta define nuestros permisos y
atributos.
 Además, asociada a esta cuenta de usuario,
tenemos un schema.
 El schema es el conjunto de objetos de la
base de datos que son propiedad de un
usuario.
3

CUENTA DE USUARIO  ATRIBUTOS
 Al crear una cuenta de usuario, podemos
definir las siguientes características:
 Su nombre
 El tablespace por defecto
 La cuota (el espacio que puede ocupar) para
este tablespace
 El tablespace temporal
 El perfil de usuario
 El status de la cuenta
4

CUENTA DE USUARIO  NOMBRE
 El nombre de usuario o username debe ser único
dentro de la base de datos.
 Debe empezar por una letra y no superar los 30
caracteres.
 No puede ser una palabra reservada.
 El nombre es case-sensitive, pero a no ser que lo
pongamos entre “”, se guardará en mayúsculas.
 Después de crear un usuario, no se puede modificar
su nombre. Debe eliminarse el usuario y volverse a
crear.
 Debemos ir con cuidado con esta acción, porque al
eliminar un usuario, se deben eliminar también todos
sus objetos (tablas, etc.)
5

CUENTA DE USUARIO  NOMBRE
6
 Conéctate en SQL*Plus con el usuario DBA
y prueba estas instrucciones:
Create user john identified by Manager11g;
Create user “john” identified by Manager11g;
Create user “john%#” identified by Manager11g;
Create user table identified by Manager11g;
Create user “table” identified by Manager11g;
Select username, created from dba_users where created>=(sysdate-1);

CUENTA DE USUARIO  TABLESPACE POR
DEFECTO
 Cada cuenta de usuario tiene un tablespace por defecto
en el que se crean sus objetos.
 Es posible que un usuario tenga objetos en más de un
tablespace si se le ha asignado una cuota. Pero, a menos
que se indique lo contrario, sus objetos se crearán en el
tablespace por defecto.
 Si no indicamos el tablespace al crear el usuario, se le
asignará el tablespace por defecto.
 Podemos modificar el tablespace por defecto con:
 ALTER DATABASE DEFAULT TABLESPACE
nombretablespace;
 Si no se indica al crear la base de datos, se considera
USERS como el tablespace por defecto.
 Es recomendable cambiarlo.
7

DEFECTO
 La cuota es la cantidad de espacio que puede ocupar
un usuario dentro del tablespace.
 Si un usuario llega a su límite, ya no puede crear
más objetos ni se puede expandir ninguno existente.
 Si se reduce la cuota de un usuario y los objetos que
tiene ya ocupan más espacio que el nuevo asignado,
los objetos continúan existiendo, pero no se le
permite crear más.
 En la siguiente diapositiva hay algunos ejemplos de
cómo comprobar el tablespace por defecto y la cuota
de cada usuario.
8

DEFECTO
9
 Conéctate en SQL*Plus con el usuario DBA y prueba estas
instrucciones:
Select username, default_tablespace, temporary_tablespace from dba_users
where created>=(sysdate-1);
Alter user john quota 10m on users;
Alter user john quota unlimited on example;
Select tablespace_name, bytes, max_bytes from dba_ts_quotas where
username=‘JOHN’;
Select property_name, property_value from database_properties where
property_name like ‘%TABLESPACE’;

CUENTA DE USUARIO  TABLESPACE
TEMPORAL
 Una sesión de usuario necesita un cierto espacio
para hacer determinadas operaciones que exceden
el espacio de su PGA.
 Este espacio se toma del tablespace temporal.
 La gestión del espacio en un tablespace temporal es
totalmente automático y no es necesario que los
usuarios tengan cuota asignada.
 Para cambiar el tablespace temporal de un usuario:
 ALTER USER username TEMPORARY TABLESPACE
nombretablespace;
10

CUENTA DE USUARIO  STATUS
 Cada cuenta tiene un status que puede consultarse en la columna
ACCOUNT_STATUS de DBA_USERS;
 Puede tomar estos valores;
 OPEN  cuenta disponible para ser utilizada.
 LOCKED  El DBA ha bloqueado la cuenta. No puede ser utilizada.
 EXPIRED  Los passwords tienen un tiempo de vida y en esta cuenta hace
falta cambiarlo.
 EXPIRED & LOCKED La cuenta ha sido bloqueada y el password ha
caducado.
 EXPIRED(GRACE)  Falta poco para que caduque el password y se va
recordando al usuario que lo tiene que cambiar.
 LOCKED (TIMED)  La cuenta se ha bloqueado porque alguien ha fallado
el password muchas veces. Se puede configurar que una cuenta se bloquee
durante un tiempo después de fallar el password un número de veces.
 EXPIRED & LOCKED (TIMED)
 EXPIRED (GRACE) & LOCKED
 EXPIRED (GRACE) & LOCKED (TIMED)
11

CUENTA DE USUARIO  STATUS
 Para bloquear y desbloquear una cuenta:
 ALTER USER username ACCOUNT LOCK;
 ALTER USER username ACCOUNT UNLOCK;
 Para forzar a un usuario que cambie su
password:
 ALTER USER username PASSWORD EXPIRE;
 Aquí no tenemos un UNEXPIRED, la única manera
de cambiar el status es resetear el password.
12

TALLER 1
Crear usuarios.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 13

PRIVILEGIOS
 Por defecto, ningún usuario puede hacer nada
contra la base de datos. Ni siquiera conectarse.
 Para conceder y recovar privilegios tenemos los
comandos GRANT y REVOKE.
 Tenemos privilegios de dos tipos:
 Privilegios de sistema
 Permiten hacer acciones que afectan al diccionario de
datos, como crear una tabla.
 Privilegios de objetos
 Permiten hacer acciones que afectan a los datos, como
consultar los datos de una tabla.
14

PRIVILEGIOS DE SISTEMA
 Existen cerca de 200 privilegios de sistema. Los más comunes son:
 CREATE SESSION  permite que el usuario se conecte a la base de
datos.
 ALTER DATABASE  permite modificar la estructura física.
 ALTER SYSTEM  permite modificar los parámetros de instancia y las
estructuras de memoria.
 CREATE/ALTER/DROP TABLESPACE  para gestionar tablespaces.
 CREATE TABLE  permite crear/modificar/borrar tablas dentro de su
schema. Van incluidos los permisos para hacer operaciones DML y SQL
contra estas tablas.
 CREATE ANY TABLE  permite crear tablas y hacer que pertenezcan a
otro usuario.
 DROP ANY TABLE  permite eliminar tablas que pertenecen a otro
usuario.
 INSERT/UPDATE/DELETE/SELECT ANY TABLE  permite hacer estas
operaciones contra tablas que no son del usuario.
15

 Ejemplo de asignación de privilegios:
 Con estos privilegios, alois puede conectarse y
crear tablas en su schema.
16
GRANT create session, create table TO
alois;

 Con la opción “with admin option”, el usuario
que lo recibe puede traspasar sus permisos
a otros usuarios.
17
Connect / as sysdba;
Grant alter system to alois with admin
option;
Connect alois/oracle;
Grant alter system to afra;

 Ejemplo para quitar un privilegio a un
usuario:
 Visualizar los privilegios de sistema que tiene
un usuario:
18
select * from dba_sys_privs where grantee = 'HR';
Revoke alter system from afra;

PRIVILEGIOS SOBRE OBJETOS
 Permite hacer SELECTs y operaciones DML sobre los
objetos.
 Estos permisos no afectan a las tablas que ha creado el
mismo usuario. Si el usuario tiene el privilegio CREATE
TABLE, también puede hacer SELECTs y DML contra las
tablas que él creó.
 Los privilegios aplicables a objetos son:
 SELECT, INSERT, UPDATE, DELETE, ALTER, EXECUTE
 Ejemplo de asignación:
19
GRANT SELECT ON hr.employees TO alois;
GRANT UPDATE(salary) on hr.employees TO alois;
GRANT ALL ON hr.regions TO alois;

TALLER 2
Conceder privilegios.

GESTIONAR ROLES
 Gestionar la seguridad asignando privilegios a
cada uno de los usuarios, funciona, pero
tenemos dos problemas:
 Mucho trabajo. En una aplicación con miles de
tablas podríamos necesitar millones de GRANTs.
 Si queremos que un privilegio debe de estar activo
durante un tiempo, tendríamos que ir usuario a
usuario quitándoselo.
 Un rol es un conjunto de privilegios que pueden
ser asignados o revocados como una unidad y
pueden ser activados o desactivados.
21

GESTIONAR ROLES
 Crear un rol:
 CREATE ROLE rolename;
 Un rol no puede tener el mismo nombre que un
usuario existente.
22

ROLES PREDEFINIDOS
 Existen al menos 50 roles predefinidos en Oracle. Los más
importantes:
 CONNECT
 Sólo tiene el privilegio de CREATE SESSION.
 Se mantiene por compatibilidad con versiones anteriores.
 RESOURCE
 Permite crear tablas y procedures.
 Además, incluye UNLIMITED TABLESPACE.
 DBA
 Tiene todos los privilegios.
 SELECT_CATALOG_ROLE
 Contiene permisos de lectura sobre objetos del diccionario de datos.
 Se utiliza con administradores junior para que pueda monitorizar la base de
datos.
 PUBLIC
 Rol que tienen asignado todos los usuarios por defecto.
 Es útil porque si queremos asignar un privilegio a todos los usuarios de la
base de datos, basta con asignárselo a este rol.
23

TALLER 3
Crear roles.

GESTIONAR PERFILES
 Los perfiles se aplican para:
 Limitar los recursos de sistema que pueden
utilizar los usuarios o los roles.
 Controlar el número de veces que fallan su
password.
25

GESTIONAR PERFILES  PASSWORDS
 Control sobre los passwords:
 FAILED_LOGIN_ATTEMPS
 Número de veces seguidas que puede fallarse un password antes
de que la cuenta sea bloqueada.
 PASSWORD_LOCK_TIME
 Número de días que la cuenta queda bloqueada después de haber
alcanzado el número anterior.
 PASSWORD_LIFE_TIME
 Tiempo de vida de un password. Se puede hacer que un password
caduque cada cierto tiempo.
 PASSWORD_GRACE_TIME
 Días después de que el password caduque en que se permite al
usuario cambiar su password.
 PASSWORD_VERIFY_FUNCTION
 El nombre de una función que se encarga de comprobar que el
password sea lo suficientemente complejo.
26

GESTIONAR PERFILES  PASSWORDS
 Control sobre los passwords:
 PASSWORD_VERIFY_FUNCTION
 Para 11g se utiliza una función que se llama
VERIFY_FUNCION_11G, que hace comprobaciones
como:
 Password de al menos 8 caracteres
 No puede ser lo mismo que el nombre de usuario.
 Deben tener al menos una letra y al menos un dígito.
 Debe diferir en al menos 3 caracteres del password anterior.
 Existen una serie de palabras que se consideran “demasiado
comunes” que no pueden ser asignadas, como por ejemplo
“oracle”.
 Esta función no existe por defecto, tenemos que crearla a
partir de script utlpwdmg.sql que tenemos en el directorio:
C:appusuariproduct11.2.0dbhome_1RDBMSADMIN
27

GESTIONAR PERFILES  RECURSOS
 Limitación de recursos:
 SESSIONS_PER_USER
 Número de sesiones que puede tener abiertas un mismo usuario.
 CPU_PER_SESSION
 Tiempo de CPU que puede consumir una sesión del usuario.
 CPU_PER_CALL
 Tiempo de CPU que se puede consumir por sentencia SQL.
 CONNECT_TIME
 Número de minutos que puede durar una sesión.
 IDLE_TIME
 Número de minutos que puede durar una sesión sin que el usuario esté
trabajando.
 Todos estos recursos no se aplican a menos que un parámetro
llamado RESOURCE_LIMIT esté activado:
 ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;
28

GESTIONAR PERFILES
 Pueden ser gestionados desde SQL*Plus o desde el
Database Control.
 Para ver qué perfiles tiene asignados cada usuario:
 SELECT USERNAME, PROFILE FROM DBA_USERS;
 Por defecto, todos los users, tienen asignados el
perfil DEFAULT.
 Para ver qué características tiene un perfil:
 SELECT * FROM DBA_PROFILES WHERE
PROFILE=‘DEFAULT’;
 Desde el Database Control, hemos de ir a la pestaña
de Servidor y lo veremos dentro de la sección de
Seguridad de Usuarios.
29

GESTIONAR PERFILES
CREATE PROFILE PROGRAMMER_PROFILE LIMIT SESSIONS_PER_USER 2
PASSWORD_LIFE_TIME 7;
ALTER USER ALOIS PROFILE PROGRAMMER_PROFILE;
DROP PROFILE PROGRAMMER_PROFILE;
-- no se puede si el perfil lo tiene asignado algún user.
DROP PROFILE PROGRAMMER_PROFILE CASCADE;
-- si el perfil está asignado a algún user,
-- pone el perfil de ese user a default.
30

TALLER 4
Gestionar perfiles.

Seguridad Oracle 11g R2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Seguridad Oracle 11g R2

Similar to Seguridad Oracle 11g R2 (20)

More from Carmen Soler

More from Carmen Soler (6)

Recently uploaded

Recently uploaded (20)

Seguridad Oracle 11g R2

Editor's Notes