Implementando la seguridad.

Category: Seguridad 12 years ago
Hola solicito su opinion referente a seguridad.

Voy a instalar una nueva aplicacion de un externo sobre oracle 10GR2, mi pregunta es. ¿Cuál es la mejor forma de implementar la seguridad para esta nueva aplicación?

Estaba pensando en crear un usuario USR1 y darle permisos de connect y resource para que este cree todos los objectos y queden con el eschema de este usuario USR1.
Después crear otro usuario USR2 que solo tuviera permisos de connect y asignarle un rol, que pudiera leer, escribir, editar, ejecutar procedures y que este fuera el que usaria la aplicacion directamente.
Aqui me sale un problema para asignarle el esquema de default del USR1, estaba pensando en poner un trigger que lo cambiara al conectarse.
Finalmente crear otros usuarios que serían el de los desarrolladores que pudieran modificar los objectos de USR1 y por supuesto insertar, borrar y modificar datos. Esto todavía estoy viendo como implementarlo.
El usuario USR1 que seria el dueño del esquema de todos los objectos lo deshabilitaria.

Que opinan de esto? Es correcto o existen formas diferentes de hacerlo?. Todo esto sería para mi servidor de desarrollo.

Gracias
Like it on Facebook, +1 on Google, Tweet it or share this topic on other bookmarking websites.
  • Re: Implementando la seguridad.

    by » 12 years ago


    Qué tal,
    Aplicando la regla de "Least privilege", yo no daría el rol resource, aunque fuera en un entorno de desarrollo. Porque si das ese rol, cuando empiece a funcionar la app y tengas que pasar todo a QA / Prod eventualmente, vas a tener la duda si diste más permisos de los necesarios y ahora no puedes quitarlos, porque ya está funcionando así en Dev y puedes generar problemas a los desarrolladores.

    Rol Resource:
    CREATE SEQUENCE
    CREATE TYPE
    CREATE TRIGGER
    CREATE CLUSTER
    CREATE PROCEDURE
    CREATE INDEXTYPE
    CREATE TABLE
    CREATE OPERATOR

    Ahora, lo que puedes hacer es una de las siguientes opciones:

    1) configurar a USR2, para que lea las tablas poniendo el esquema antes del objeto. Ej. "USR1.TABLA".

    2) Si quieres que todos puedan leer esas tablas, puedes crearles un sinónimo público, así los usuarios ya no tendrán que especificar el usuario. Aunque es riesgoso esto.

    3) Crear un trigger de evento "after logon", que valide el usuario y en caso de serlo, que altere su sesión de la siguiente forma:

    [code:1]
    CREATE OR REPLACE TRIGGER alter_schm_for_SR2user
    AFTER LOGON on DATABASE
    BEGIN
    IF ( user = 'SR2' ) THEN
    execute immediate
    'ALTER SESSION SET CURRENT_SCHEMA=SR1';
    END IF;
    END;
    /
    [/code:1]


    Internamente esto es lo que sucederá:

    [code:1]
    SQL> select * from mytable123;
    select * from mytable123
    *
    ERROR en línea 1:
    ORA-00942: la tabla o vista no existe


    SQL> ALTER SESSION SET CURRENT_SCHEMA = SR1;

    Sesión modificada.

    SQL> select * from mytable123;

    F1
    ----------
    1233
    [/code:1]

    Salu2.
    Carlos I. Contreras<br><br>Post edited by: CContreras, at: 2009/06/02 10:58

    DBASupport Team

  • Re: Implementando la seguridad.

    by » 12 years ago


    Bueno el usr1 sería bloqueado y solo se utilizaría en caso de modificar los objetos en la base de datos, el que en realidad usaría la aplicación seria el usr2. Ahora me gusta la idea del trigger, pero como podría hacerlo más general por ejemplo para los desarrolladores. Se podría crear algún grupo en el que los que pertenecieran a el se les aplicara el trigger que cambiara su esquema de default.

    Gracias

  • Re: Implementando la seguridad.

    by » 12 years ago


    Qué tal...
    No sé qué factor en común tengan esos developers. Supongo que no se conectan con el mismo nombre de usuario. Puedes buscar algo que tengan en común.


    Por ejemplo, yo para identificar a los desarrolladores, si le voy a crear un usuario a Marco, le pongo &quot;DEV_MARCO&quot; como user name.

    Entonces en el trigger sería...if (user like &quot;DEV_%) then&quot;

    Otra es buscar el factor en común, mediante la función SYS_CONTEXT... con esta función puedes obtener muchísima información sobre la conxión del usuario que se esté conectando... te paso algunas de las cosas que puedes obtener con dicha función:


    [code:1]
    SYS_CONTEXT('USERENV','TERMINAL') terminal,
    SYS_CONTEXT('USERENV','LANGUAGE') language,
    SYS_CONTEXT('USERENV','SESSIONID') sessionid,
    SYS_CONTEXT('USERENV','INSTANCE') instance,
    SYS_CONTEXT('USERENV','ENTRYID') entryid,
    SYS_CONTEXT('USERENV','ISDBA') isdba,
    SYS_CONTEXT('USERENV','NLS_TERRITORY') nls_territory,
    SYS_CONTEXT('USERENV','NLS_CURRENCY') nls_currency,
    SYS_CONTEXT('USERENV','NLS_CALENDAR') nls_calendar,
    SYS_CONTEXT('USERENV','NLS_DATE_FORMAT') nls_date_format,
    SYS_CONTEXT('USERENV','NLS_DATE_LANGUAGE') nls_date_language,
    SYS_CONTEXT('USERENV','NLS_SORT') nls_sort,
    SYS_CONTEXT('USERENV','CURRENT_USER') current_user,
    SYS_CONTEXT('USERENV','CURRENT_USERID') current_userid,
    SYS_CONTEXT('USERENV','SESSION_USER') session_user,
    SYS_CONTEXT('USERENV','SESSION_USERID') session_userid,
    SYS_CONTEXT('USERENV','PROXY_USER') proxy_user,
    SYS_CONTEXT('USERENV','PROXY_USERID') proxy_userid,
    SYS_CONTEXT('USERENV','DB_DOMAIN') db_domain,
    SYS_CONTEXT('USERENV','DB_NAME') db_name,
    SYS_CONTEXT('USERENV','HOST') host,
    SYS_CONTEXT('USERENV','OS_USER') os_user,
    SYS_CONTEXT('USERENV','EXTERNAL_NAME') external_name,
    SYS_CONTEXT('USERENV','IP_ADDRESS') ip_address,
    SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') network_protocol,
    SYS_CONTEXT('USERENV','BG_JOB_ID') bg_job_id,
    SYS_CONTEXT('USERENV','FG_JOB_ID') fg_job_id,
    SYS_CONTEXT('USERENV','AUTHENTICATION_TYPE') authentication_type,
    SYS_CONTEXT('USERENV','AUTHENTICATION_DATA') authentication_data,
    SYS_CONTEXT('USERENV','CURRENT_SQL') current_sql,
    SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') client_identifier,
    SYS_CONTEXT('USERENV','GLOBAL_CONTEXT_MEMORY')
    [/code:1]

    Y un ejemplo del trigger con esta función de sys_context... suponiendo que todas los hostnames de los PCs de los desarrolladores, comienzan con &quot;PC_DBASupport&quot;, por ejemplo: PC_DBASupport01, PC_DBASupport03, PC_DBASupport05...


    [code:1]
    CREATE OR REPLACE TRIGGER &quot;LOGON_AUDIT_GLORIA_TRIGGER&quot; AFTER
    LOGON ON DATABASE
    BEGIN
    IF sys_context('USERENV','HOST') like 'PC_DBASupport%'
    THEN
    execute immediate
    'ALTER SESSION SET CURRENT_SCHEMA=SR1';
    END IF;
    END;
    /
    [/code:1]


    Otra opción es creando un rol o usando uno que ya tengan asignado solamente estos desarrolladores. Así, en la validacion del trigger, revisas DBA_ROLES y si ese usuario pertenece a ese rol, le cambia la sesión con el execute.

    Esto lo puedes hacer en un procedimiento almacenado, de tal forma que el trigger lo ejecute. De esta forma mejoras el performance de dicha validación.

    Saludos,
    Carlos Contreras.
    DBASupport.<br><br>Post edited by: CContreras, at: 2009/06/08 06:54

    DBASupport Team

  • Re: Implementando la seguridad.

    by » 12 years ago


    Ok muchas gracias, me gusto mucho tu idea.

    Saludos

You do not have permissions to reply to this topic.
Powered by CjForum