Skip to main content

Usuarios y Vistas

Gestión de Usuarios y desarrollo de vistas

Un SGBD puede gestionar diferentes BD, estas a su vez pueden tener diferentes esquemas en su interior. Por ejemplo Postgresql nos permite crear todos los esquemas que necesitemos. Mientras que ORACLE nos crea uno por cada usuario que tenga la BD.

El propietario de cada objeto(esquema,tabla,vista) es que dará permisos a los otros usuarios sobre este objeto.

Postgresql crea por defecto el esquema público. Si creamos el usuario user1 y no le asignamos ningún esquema, los objetos que cree este usuario irán a parar al esquema público.

Permisos

  • OWNER
    • DB
      • SCHEMA (USAGE,CREATE)
        • TABLE (SELECT,INSERT,UPDATE,DELETE,REFERENCES)

PROBLEMAS DE SEGURIDAD

  1. Confidencialidad.
  2. Integridas. Los datos han de estar protegidos de modificaciones no autorizadas así como, la inserción de datos falsos.
  3. Disponibilidad.

AMENAZAS Y VIOLACIONES DEL SISTEMA

Será considerado agente hostil todo aquel que:

  • Haga una lectura inadecuada de la información. Usuarios no autorizados.
  • Modificación impropia de los datos.
  • Denegación de servicio.
  1. Amenazas no fraudulentas.
    1. Desastres naturales o accidentales.
    2. Errores del sistema.
    3. Errores humanos.
  2. Amenazas fraudulentas.
    1. Usuarios autorizados.
    2. Agentes hostiles o usuarios impropios.

LOGIN

  1. Identificació. Qui soc.
  2. Autentificació. Verificar qui soc.

Control de Acceso MAC

  • No classificado (u).
  • Confidencial (c).
  • Secreto (s).
  • Top Secret (TS).

Siguiendo esta clasificación si el sujeto tiene mayor o igual clasificación que el objeto podrá leer dicha información y todas las de nivel inferior.

Para que haya una modificación el sujeto y el objeto deben tener la misma clasificación. Un usuario con clasificacion (s) no puede modificar una tabla con clasificación (c).

Control de acceso DAC. El utilizado por Postgresql.

ROL = Perfil

Hay diferentes modalidades.

  1. USER. Modalidad para un único individuo, tienen que hacer “login”.
  2. GROUP. Modalidad para más de un usuario.

Privilegios sobre un esquema (schema)

El usuario postgres crea una BD, después crea un usuario y hace propietario de la BD a este.

./createdb nombre_base

CREATE ROLE user1 LOGIN PASSWORD’user1′ INHERIT;
ALTER DATABASE nombre_base OWNER TO  user1;
CREATE SCHEMA administradores;

 

Para el esquema podemos utilizar dos tipos de permisos, CREATE and USAGE. Si tenemos permisos de crear pero no tenemos permisos de usar no podremos hacer demasiado.

CREATE ROLE admins INHERIT;
CREATE ROLE losers NOINHERIT;
GRANT CREATE, USAGE ON SCHEMA administradores TO admins;
GRANT CREATE, USAGE ON SCHEMA administradores TO losers;
GRANT admins,losers TO user1;

Vistas

Las vistas de diferentes tablas o esquemas nos aportan seguridad. Dando un visión particular de la base de datos a los usuarios dependiendo de sus funciones. También la podemos considerar para almacenar consultas complicadas y tediosas de realizar.

CREATE VIEW nombre_vista(lista de campos) AS “CONSULTA”;

Para borrar una vista:

DROP VIEW nombre_vista;

Vistas actualizables

Para que una vista sea actualizable, es decir, que podemos hacer en ella un INSERT, UPDATE or DELETE, debe de cumplir las siguentes condiciones.

  1. No tener más de una tabla en la consulta. (Esto se puede mejorar mediante reglas de inserción, actualización y borrado.)
  2. La definición de la vista no puede tener los comandos WITH, DISTINCT, GROUP BY, HAVING,LIMIT OR OFFSET.
  3. No puede haver consultas con INTERSECT, UNION, EXCEPT
  4. La consultas no pueden tener funciones de agregación (SUM,COUNT,MAX,MIN,ETC.)

Reglas de inserción

Regla de inserción para un nuevo departamento.

CREATE OR REPLACE RULE ins_departament_nou AS
ON INSERT TO professors.departament_profes_view
WHERE NEW.codi_departament IS NOT NULL
AND NEW.id_professor IS NOT NULL
DO INSTEAD
( INSERT INTO professors.departament(codi,nom)
VALUES (NEW.codi_departament, NEW.nom_departament);
INSERT INTO professors.professor(id,nom, sou, datainici, codidep)
VALUES (NEW.id_professor, NEW.nom_professor, 1000, current_date, NEW.codi_departament);

);

 

Regla de inserción para un departamento existente.

CREATE OR REPLACE RULE ins_departament_existente AS
ON INSERT TO professor.departament_profes_view
WHERE NEW.codi_departament IN SELECT DISTINCT codi FROM departament
DO INSTEAD
(
INSERT INTO professors.professor(id,nom,sou,datainici,codidep) VALUES
(NEW.id_professor, NEW.nom_professor, 1000, current_date,
NEW.codi_departament);
);

Regla de inserción condicional

CREATE OR REPLACE RULE ins_departament_nothing AS
ON INSERT INTO professors.departament_profes_view
DO INSTEAD NOTHING;
GRANT SELECT, INSERT ON TABLE professors.professor TO administratiu;
GRANT SELECT, INSERT ON TABLE professors.departament TO administratiu;
INSERT INTO
professors.departament_profes_view(codi_departament,nom_departament,id_professor,nom_professor)
VALUES (‘RH’,’Recursos_Humanos’ ,’6′,’Manolo’);
Back to top