1 Posibilidades
Oracle pone al alcance del DBA varios niveles de seguridad:
- Seguridad de cuentas para la validación de usuarios.
- Seguridad en el acceso a los objetos de la base de datos.
- Seguridad a nivel de sistema para la gestión de privilegios globales.
1.1 Seguridad de Cuentas
Para acceder a los datos en una BD Oracle, se debe tener acceso a una cuenta en esa BD. Cada cuenta debe tener una palabra clave o password asociada. Una cuenta en una BD puede estár ligada con una cuenta de sistema operativo. Los passwords son fijados cuando se crea un usuario y pueden ser alterados por el DBA o por el usuario mismo. La BD almacena una versión encriptada del password en una tabla del diccionario llamada dba_users. Si la cuenta en la BD está asociada a una cuenta del sistema operativo puede evitarse la comprobación del password, dándose por válida la comprobación de la identidad del usuario realizada por el SO.
1.2 Seguridad de Objetos
El acceso a los objetos de la BD se realiza via privilegios. Estos permiten que determinados comandos sean utilizados contra determinados objetos de la BD. Esto se especifica con el comando GRANT, conceder. Los privilegios se pueden agrupar formando lo que se conoce por roles. La utilización de los roles simplifica la administración de los privilegios cuando tenemos muchos usuarios. Los roles pueden ser protegidos con passwords, y pueden activarse y desactivarse dinámicamente, con lo que constituyen una capa más de seguridad en el sistema.
1.3 Roles del Sistema
Los roles se pueden utilizar para gestionar los comandos de sistema disponibles para los usuarios. Estos incluyen comandos como CREATE TABLE o SELECT ANY TABLE. Todos los usuarios que quieran acceder a la BD deben tener el rol CONNECT; aquellos que necesiten crear segmentos necesitaran el rol RESOURCE. Un usuario con el rol DBA tiene derecho para ver y manejar todos los datos de la BD. En Oracle CONNECT, RESOURCE y DBA son roles de sistema. Las acciones contra cada tipo de objeto son autorizadas por privilegios separados. Así, un usuario puede tener concedido el privilegio CREATE TABLE, pero no el ALTER TABLE.
2 Implementación de Seguridad
No se podrá acceder a la BD a menos que se acceda primero al servidor en el que la BD está ejecutándose. El primer paso en la seguridad de la BD es asegurar la plataforma en la que reside. Una vez que esto ha sido conseguido, se debe considerar la seguridad del sistema operativo. Oracle utiliza una serie de ficheros a los que los usuario no tienen porque acceder de manera directa. Por ejemplo, los ficheros de datos o los de redo log son escritos y leidos sólo por los procesos Oracle. Así, sólo los DBAs que han creado estos ficheros necesitan acceder directamente a ellos a nivel del sistema operativo.
2.1 Creación de Usuarios
El objetivo de la creación de usuarios es establecer una cuenta segura y útil, que tenga los privilegios adecuados y los valores por defecto apropiados. En Oracle se puede especificar todo lo necesario para abrir una cuenta con el comando CREATE USER. Los parámetros que se le pueden pasar son:
| Parámetro | Significado |
| Username | Nombre del Usuario (Esquema) |
| Password | Palabra clave de la cuenta. Puede ser asociada directamente a una cuenta del sistema operativo. |
| Default Tablespace | Espacio de tablas por defecto en el que los objetos de este usuario serán creados. Esto no da al usuario derechos de crear objetos. |
| Temporary Tablespace | El espacio de tablas en el que se almacenarán los segmentos temporales de las ordenaciones. |
| Quota | Espacio máximo que puede ocupar en un espacio de tablas. |
| Profile | Asigna un perfil al usuario. Los perfiles se utilizan para restringir el uso de recursos como el tiempo de CPU. |
A continuación se puede ver un ejemplo de uso del comando CREATE USER en el que se crea una cuenta para el usuario Pérez:
SVRMGR> create user perez
2> identified by zerep
3> default tablespace users
4> temporary tablespace temp;
Si no se especifica un perfil, se aplica el perfil por defecto de la BD, que se llama DEFAULT y tiene asignados todos los límites a UNLIMITED.
Si no se especifíca una cuota el usuario no puede crear objetos.
2.2 Eliminación de Usuarios
Los usuarios pueden ser eliminados de la BD utilizando el comando DROP USER. Este comando tiene un único parámetro, CASCADE, el cual permite borrar todos los objetos del usuario antes de eliminar el usuario.
A continuación un ejemplo en el que eliminamos al usuario Pérez:
SVRMGR> drop user perez cascade;
Si a continuación se crea otro usuario con el mismo nombre no hereda los objetos del anterior usuario con ese nombre. La razón estriba en que Oracle asigna a cada cuenta un número además del nombre, y utiliza ese número para determinar el propietario de todos los objetos que crea esa cuenta, y no utiliza el nombre sino para la comunicación con los usuarios. De este modo al crear un nuevo usuario, aunque sea con el mismo nombre, no puede heredar los objetos que antes eran de otro usuario con el mismo nombre.
2.3 Privilegios del Sistema
Los roles de sistema se utilizan para distribuir la disponibilidad de los comandos del sistema utilizados para gestionar la BD. Los privilegios más comunes están en la siguiente tabla. En ella se distinguen entre privilegios de manejo de objetos y de gestión de la BD. La palabra clave ANY significa que ese usuario tiene el privilegio para todos los esquemas en la BD. Hay que hacer notar que ANY y PUBLIC no son sinónimos.
| Privilegio | Capacidades |
| Manejo de Objetos | ... |
| CREATE ANY INDEX | Crear cualquier índice. |
| CREATE [PUBLIC] SYNONYM | Crear sinónimos [públicos]. |
| CREATE [ANY] TABLE | Crear tablas. El usuario debe tener cuota en el espacio de tablas, o ha de tener asignado el privilegio UNLIMITED TABLESPACE. |
| CREATE [ANY] VIEW | Crear vistas. |
| ALTER ANY INDEX | Alterar cualquier índice. |
| ALTER ANY TABLE | Alterar cualquier tabla |
| DROP ANY INDEX | Borrar cualquier índice. |
| DROP ANY SYNONYM | Borrar cualquier sinónimo. |
| DROP PUBLIC SYNONYM | Borrar sinónimos públicos. |
| DROP ANY VIEW | Borrar cualquier vista. |
| DROP ANY TABLE | Borrar cualquier tabla. |
| SELECT ANY TABLE | Efectuar selecciones de cualquier tabla o vista. |
| INSERT ANY TABLE | Insertar en cualquier tabla o vista. |
| DELETE ANY TABLE | Borrar filas de cualquier tabla o vista, y también truncar. |
| ALTER SESSION | Alterar los parámetros de la sesión. |
| CREATE SESSION | Conectarse a la BD. |
| Gestión de la BD | ... |
| CREATE PROFILE | Crear perfiles de usuario. |
| CREATE ROLE | Crear roles. |
| CREATE ROLLBACK SEGMENT | Creación de segmentos de rollback. |
| CREATE TABLESPACE | Crear espacios de tablas. |
| CREATE USER | Crear usuarios. |
| ALTER PROFILE | Alterar perfiles existentes. |
| ALTER ANY ROLE | Alterar cualquier rol. |
| ALTER ROLLBACK SEGMENT | Alterar segmentos de rollback. |
| ALTER TABLESPACE | Alterar espacios de tablas. |
| ALTER USER | Alterar usuarios. |
| DROP PROFILE | Borrar un perfil existente. |
| DROP ANY ROLE | Borrar cualquier rol. |
| DROP ROLLBACK SEGMENT | Borrar un segmento de rollback existente. |
| DROP TABLESPACE | Borrar un espacio de tablas. |
| DROP USER | Borrar un usuario. Añadir CASCADE si el usuario posee objetos. |
| ALTER DATABASE | Permite una sentencia ALTER DATABASE. |
| GRANT ANY PRIVILEGE | Otorgar cualquiera de estos privilegios. |
| GRANT ANY ROLE | Otorgar cualquier rol a un usario. |
| UNLIMITED TABLESPACE | Puede usar una cantidad de almacenamiento ilimitada. |
| DROP PROFILE | Borrar un perfil existente. |
Los privilegios se pueden agrupar en roles, para así satisfacer a distintos tipos de usuarios. En la instalación se crea un rol llamado OSOPER que sirve para los operarios de la máquina donde está la BD y permite realizar copias de seguridad en frio y en caliente. Los privilegios de OSOPER son STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP, ARCHIVE LOG, RECOVER y RESTRICTED SESSION.
Se pueden crear nuevos roles. Por ejemplo, podemos crear un rol llamado creadorCuentas que sólo pueda crear usuarios y no pueda realizar ninguna otra operación de DBA. Las sentencias que permiten hacer esto son las siguientes:
SVRMGR> create role creadorCuentas;
Statement processed.
SVRMGR> grant create session, create user to creadorCuentas;
Statement processed.
Oracle incluye otros tres roles de sistema: CONNECT, RESOURCE y DBA, cuyos privilegios son:
| Rol | Privilegios |
| CONNECT | alter session, create session, create cluster, create table, create view, create synonym, create sequence, create database link |
| RESOURCE | create cluster, create table, create procedure, create sequence, create trigger |
| DBA | todos los privilegios de sistema con la opcion with admin option |
2.4 Perfiles de Usuario
Los perfiles se utilizan para limitar la cantidad de recursos del sistema y de la BD disponibles para un usuario. Si no se definen perfiles para un usuario se utiliza el perfil por defecto, que especifica recursos ilimitados.
Los recursos que pueden ser limitados via perfil son los siguientes:
| Recurso | Descripción |
| SESSIONES_PER_USER | El número de sesiones concurrentes que un usuario puede tener en una instancia. |
| CPU_PER_SESSION | El tiempo de CPU, en centenas de segundos, que una sesión puede utilizar. |
| CONNECT_TIME | El número de minutos que una sesión puede permanecer activa. |
| IDLE_TIME | El número de minutos que una sesión puede permanecer sin que sea utilizada de manera activa. |
| LOGICAL_READS_PER_SESSION | El número de bloques de datos que se pueden leer en una sesión. |
| LOGICAL_READS_PER_CALL | El número de bloques de datos que se pueden leer en una operación. |
| PRIVATE_SGA | La cantidad de espacio privado que una sesión puede reservar en la zona de SQL compartido de la SGA. |
| COMPOSITE_LIMIT | El número de total de recursos por sesión, en unidades de servicio. Esto resulta de un calculo ponderado de CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION y PRIVATE_SGA, cuyos pesos se pueden variar con el comando ALTER RESOURCE COST. |
Los perfiles se pueden crear via el comando CREATE PROFILE, y se pueden modificar con la sentencia ALTER PROFILE.
En general, el perfil por defecto debe ser adecuado para los usuarios normales; los usuarios con requerimientos especiales deberían tener perfiles especiales.
2.5 Cuentas BD sobre Cuentas SO
Los usuarios pueden entrar en la BD una vez que han dado un nombre de usuario y una palabra de paso. Sin embargo, es posible aprovecharse del Sistema Operativo para obtener un nivel adicional de autentificación.
La cuenta de la BD y del SO pueden relacionarse de manera que la de la BD se diferencie sólo en un prefijo de la cuenta del SO. Este prefijo se fija en el parámetro OS_AUTHENTIC_PREFIX del fichero init.ora. Por defecto esta puesto a "OPS$", pero puede tomar cualquier forma, incluso ser la cadena nula, "", con lo que no existe prefijo que diferencie las cuentas en la BD y en el SO.
Por ejemplo, consideremos la cuenta del SO llamada alu10. La correspondiente cuenta en la BD sería OPS$ALU10. Cuando el usuario alu10 está en activo en el SO, puede acceder a su cuenta OPS$ALU10 sin especificar el password, como se muestra a continuación:
$ sqlplus /
En este caso el carácter "/" toma el lugar de la combinación del nombre de usuario y del password que debería aparecer.
Las cuentas pueden ser creadas con passwords aunque no vaya a ser utilizado. Ya que de este modo será posible acceder a la cuenta de OPS$ALU10 desde otra cuenta diferente a la alu10 del SO. La sentencia de creación de la cuenta OPS$ALU10 puede ser la siguiente:
SVRMGR> create user ops$alu10
2> identified by 01ula
3> default tablespace users
4> temporary tablespace temp;
Así, la forma de conectarse como OPS$ALU10 desde una cuenta del SO diferente es:
$ sqlplus ops$alu10/01ula
Existen dos formas de evitar este problema. La primera es creando el usuario BD sin especificar un password, utilizando la claúsula IDENTIFIED EXTERNALLY. De esta manera evitamos la necesidad de expecificar un password para la cuenta, obligando a la conexión entre las cuentas de la BD y del SO:
SVRMGR> create user ops$alu10
2> identified externally
3> default tablespace users
4> temporary tablespace temp;
La otra manera de evitar el problema es crear una cuenta con un password imposible, aspecto este que se explicará más adelante.
2.6 Protegidos por passwords
Los passwords puede proteger tanto cuentas como roles. Los passwords se fijan a la hora de la creación de ambos y se pueden modificar con los comandos ALTER USER y ALTER ROLE, respectivamente.
No es necesario asignar un password a un rol, pero si tiene uno debe ser especificado por el usuario cuando se asigna ese rol.
No hay comentarios:
Publicar un comentario