SEGURIDAD
Seguridad se refiere a la protección de los datos contra una alteración o destrucción no
autorizada.
La seguridad implica asegurar que los usuarios están autorizados para llevar a cabo lo que
tratan de hacer.
El problema de la seguridad tiene muchos aspectos, como ser:
Aspectos legales, sociales y éticos.
Controles físicos.
Cuestiones de política interna.
Problemas de operación.
Controles del equipo.
Seguridad del sistema.
Materias de relevancia específica para el sistema mismo de BD.
Un usuario dado tendrá diferentes derechos de acceso o autorizaciones sobre diferentes
objetos de información. Por supuesto todas las decisiones son de política, no técnicas. Lo único
que puede hacer el DBMS es obligar el cumplimiento de esas decisiones una vez tomadas. Para
ello cuenta con:
● Los resultados de esas decisiones deben darse a conocer al sistema (en SQL se usa
GRANT (conceder) y REVOKE (revocar), y el sistema las graba en el catálogo en forma de
restricciones de autorización).
● Debe existir alguna forma de verificar una solicitud de acceso dada contra las
restricciones de autorización aplicables. Para poder decidir cuáles restricciones son
aplicables a una solicitud dada, el sistema debe ser capaz de reconocer el origen de
dicha solicitud: o sea, al usuario específico del cual proviene.
VISTAS Y SEGURIDAD
Para mostrar el empleo de las vistas con propósitos de seguridad, nos basaremos en la tabla
PROVEEDORES.
Para un usuario al cual se permite tener acceso a registros completos de proveedores pero sólo
de los situados en Avellaneda:
CREATE VIEW V_PROVEEDORES _ AVELLANEDA AS
SELECT NUMERO, NOMBRE, SITUACION, LOCALIDAD
FROM PROVEEDORES
WHERE LOCALIDAD = ‘AVELLANEDA’;
Las vistas ofrecen una importante medida de seguridad. Hacen posible dividir conceptualmente
la base de datos en fragmentos de distintas maneras con objeto de ocultar información
confidencial a usuarios no autorizados. Sin embargo, resulta un poco débil sobre todo en
situaciones como si algún usuario en particular necesita diferentes derechos sobre diferentes
subconjuntos de la misma tabla al mismo tiempo.
GRANT (conceder) y REVOKE (revocar)
Permite especificar las operaciones que los usuarios autorizados pueden ejecutar con esos
fragmentos.
En general, para poder realizar cualquier operación en SQL, incluso un simple SELECT, el
usuario debe contar con la autorización apropiada.
En un motor de base de datos existen autorizaciones relacionadas con utilerías específicas del
sistema, con áreas de almacenamiento temporal específicos de la base de datos, etc.
Para que los usuarios accedan a la base y a los objetos deben tener privilegios otorgados. El
DBA debe controlar los privilegios, lo que implica:
• Proveer al usuario los permisos necesarios para ejecutar un tipo de operación.
• Habilitar y restringir los accesos y cambios de los datos.
• Habilitar y restringir la posibilidad de ejecutar funciones del sistema y cambiar la estructura
de la base de datos.
• Otorgar privilegios a usuarios individuales y a roles.
• Otorgar privilegios a todos los usuarios (PUBLIC)
Existen 2 tipos de privilegios:
• Privilegios del sistema (Privilegios sobre operaciones de DDL):
Permiten al usuario realizar una o varias operaciones especiales. Un privilegio del sistema es el
derecho de ejecutar una clase de comando y no son específicos a un esquema. Cada privilegio
le permite al usuario realizar una operación específica. El alcance de los privilegios del sistema
puede abarcar por ej. Crear una tabla en su esquema, en cualquier esquema, crear usuarios o
cambiar la estructura de la base de datos, etc.
• Privilegios sobre objetos (Privilegios sobre operaciones de DML):
Permiten que los usuarios puedan manipular las tablas, vistas, secuencias o ejecutar
procedimientos almacenados. Los privilegios de objetos se deben otorgar para cada uno de los
objetos, no hay forma de otorgarlos agrupadamente por objetos, salvo mediante el uso de
roles.
Supongamos que el administrador quiere conceder derechos a algún usuario.
La concesión de esos privilegios se realiza mediante la proposición GRANT (tanto para
privilegios del sistema como de objetos).
La sintáxis para otorgar privilegios del sistema es la siguiente:
GRANT priv_sistema TO user
Role role
public
Ejemplo:
GRANT ALTER ANY TABLE TO CARLOS;
GRANT ALTER DATABASE TO JOSE;
GRANT CREATE TABLE TO MARIA, CARLOS;
GRANT DROP ANY TABLE TO JUAN;
La sintáxis para otorgar privilegios sobre objetos es la siguiente:
GRANT priv_objeto ON objeto TO user
ALL role
public
Ejemplos:
GRANT SELECT ON PROVEEDORES TO BRUNO;
GRANT SELECT, INSERT (NPROV,NOMBRE), UPDATE (SITUACION) ON PROVEEDORES TO
PEDRO, MARIA;
GRANT ALL ON PROVEEDORES, PRODUCTOS TO MAURO, JULIO;
GRANT SELECT ON PRODUCTOS TO PUBLIC;
SINONIMOS:
Para realizar una identificación completa de un objeto de base de datos (como una tabla o una
vista) es necesario especificar el propietario del objeto y el nombre del objeto. Serán necesarios
entre uno y cuatro de estos parámetros en función del desplazamiento del objeto. Los
desarrolladores pueden crear sinónimos que apunten al objeto adecuado para ocultar este
proceso a los usuarios, que sólo tienen que conocer el nombre del sinónimo.
Los sinónimos públicos los comparten todos los usuarios de una base de datos, mientras que
los sinónimos privados pertenecen a propietarios individuales.
Por ejemplo, la tabla EMPLEADOS debe ser propiedad de una cuenta (digamos que el
propietario es HR). Desde otra cuenta de usuario de la misma base de datos, dicha tabla podría
referenciarse como [Link]. No obstante, esto implica que la segunda cuenta debe
conocer que la tabla EMPLEADOS es propiedad de la cuenta HR. Para evitar esto, puede crearse
un sinónimo público llamado EMPLEADOS que apunte a [Link].
Siempre que se haga referencia a este sinónimo apuntará a la tabla adecuada.
La siguiente sentencia SQL permite crear dicho sinónimo:
CREATE PUBLIC SYNONYM empleados FOR [Link];
Los sinónimos permiten proporcionar punteros a tablas, vistas, procedimientos, funciones,
paquetes y secuencias.
Revoke
También se puede revocar dichas autorizaciones o privilegios con REVOKE.
La sintáxis para revocar privilegios del sistema es la siguiente:
REVOKE priv_sistema FROM user
role role
public
Ejemplo:
REVOKE ALTER ANY TABLE FROM CARLOS;
REVOKE ALTER DATABASE FROM JOSE;
La sintáxis para revocar privilegios sobre objetos es la siguiente:
REVOKE priv_objeto ON objeto FROM user
A ALL role
public
Ejemplo:
REVOKE SELECT ON PROVEEDORES FROM BRUNO;
REVOKE UPDATE ON PROVEEDORES FROM MANUEL;
REVOKE INSERT, DELETE ON PROV-PROD FROM ANA, JUAN;
REVOKE ALL ON PROVEEDORES, PRODUCTOS, PROV-PROD FROM FERNANDO;
SEGURIDAD – ADMINISTRACIÓN POR ROLES
Cuando se tienen muchas tablas y/o muchos usuarios lo recomendado es utilizar una política
de permisos a través de roles.
Los roles sirven para simplificar el otorgamiento de privilegios y permisos. Son un grupo de
permisos que son concedidos a usuarios u otros roles.
Las características de los roles son:
• No pertenece a ningún esquema, pertenece a la base de datos.
• Puede ser otorgado a otros roles, excepto a sí mismo. (el role A no se puede otorgar al role
B, si el role B ya ha sido otorgado al role A)
• Puede ser habilitado o no por cada usuario.
• Está documentado en el diccionario de datos.
Beneficios de los roles:
• Reducen el tiempo al otorgar/revocar permisos: se pueden otorgar/revocar muchos
privilegios con una sola sentencia.
• Administración dinámica: cuando cambia la funcionalidad de un role, basta cambiar el role
para que sean alterados los privilegios de todos los usuarios asociados.
• Performance: pocos privilegios individuales para controlar.
La sintáxis para la creación de un role es:
CREATE ROLE NOMBRE_ROLE;
Roles por defecto:
Luego que fueron otorgados los roles al usuario, se puede indicar cuáles serán por defecto
y cuáles no. Cuando el usuario se conecte, los roles por defecto serán automáticamente
habilitados.
En caso de no indicarse cuáles son los roles por defecto, todos los roles serán considerados
por defecto, produciendo que todos los roles sean automáticamente habilitados cuando el
usuario se conecte.
Para establecer los roles por defecto se debe usar el comando ALTER USER.
ALTER USER usuario DEFAULT ROLE role, role.
All
None
Ejercicios:
1) Crear una vista para un usuario al cual se permite tener acceso a todos los registros de
proveedores pero sin las situaciones. Luego asignarle permisos a un usuario sobre esa vista.
2) Crear una vista para un usuario al cual se permite tener acceso sólo a los registros de los
proveedores situados en Avellaneda, sin las situaciones. Luego asignarle permisos a un
usuario sobre esa vista.
3) La tabla DATPERS se define así:
CREATE TABLE DATPERS (
IDENTUSUARIO VARCHAR (8)
SEXO VARCHAR (1)
DEPENDIENTES DECIMAL (2)
OCUPACIÓN VARCHAR (20)
SALARIO DECIMAL (7)
IMPUESTO DECIMAL (7)
AUDITORÍAS DECIMAL (2)
PRIMARY KEY (IDENTUSUARIO) )
Escribir proposiciones en SQL para conceder lo siguiente:
A) Al usuario Gómez, autorización de selección sobre toda la tabla.
B) Al usuario López, autorización de inserción y eliminación sobre toda la tabla.
C) Al usuario Sánchez, autorización de selección sobre toda la tabla y autoridad de
actualización sobre los campos SALARIO e IMPUESTO (solamente).
D) Al usuario Torres, autorización de selección sobre los campos IDENTUSUARIO, SALARIO
e IMPUESTO (únicamente).
E) Al usuario Pérez, autorización de selección igual a la de Torres y autorización de
actualización sobre los campos Salario e Impuesto (solamente).
F) Al usuario Villalba, autorización de selección sobre los registros de predicadores
(únicamente). (Predicadores es un tipo de ocupación).
G) Al usuario Giménez, autorización de selección igual a la de Torres y autoridad de
actualización sobre los campos IMPUESTO y AUDITORIA (únicamente).
H) Al usuario Aguero, autorización de selección sobre los salarios máximos y mínimos por
clase de ocupación pero ninguna otra autorización.
4) Para cada una de las partes (a) - (h) del ejercicio anterior escribir proposiciones en SQL
para retirar la autorización indicada al usuario en cuestión.