Preparación para el examen 730 Fundamentos DB2 9, Parte 2: Seguridad

Este tutorial introduce los conceptos de autenticación, autoridad y privilegios, en cuanto a cómo se relacionan con DB2® 9. Este es el segundo de una serie de siete tutoriales diseñados para ayudarle a prepararse para el Examen de Certificación en Fundamentos (730) DB2 9. Usted debe tener conocimientos básicos sobre conceptos de bases de datos y de seguridad de sistemas operativos. Este es el segundo de una serie de siete tutoriales para ayudarle a prepararse para el examen 730 sobre Fundamentos DB2 9 for Linux®, UNIX® y Windows® .

Graham G. Milne, I/T Specialist DB2 UDB, IBM Canada

Graham Milne, HBSc. - Ciencias de la computación, es DB2 Certified Advance Technical Expert y ha estado trabajando con DB2 desde 1998. Actualmente Graham es Premium Support Manager para DB2, dando soporte a clientes premium grandes. Antes de esto, era consultor sénior de servicio avanzado para el soporte DB2 basado en el IBM Toronto Software Lab.



31-03-2014

Antes de comenzar

Sobre esta serie

¿Está pensando en obtener la certificación en fundamentos DB2 (Examen 730)? Si es así, ha llegado al lugar correcto. Esta serie de siete tutoriales de preparación para la certificación DB2 cubre todo lo básico (los temas que necesitará entender antes de leer la primera pregunta del examen). Incluso si usted no está pensando en obtener la certificación justo ahora, este conjunto de tutoriales es un excelente lugar para comenzar a saber qué hay de nuevo en DB2 9.

Acerca de este tutorial

En este tutorial, usted aprenderá sobre los recursos de seguridad DB2 9, incluyendo la autenticación, autoridad y privilegios en DB2 9.

Este es el segundo de una serie de siete tutoriales que usted puede usar para prepararse para el Examen (730) de Certificación en Fundamentos DB2 9. El material de esta tutorial principalmente cubre los objetivos de la Sección 2 de la prueba, titulada "Seguridad". Usted puede ver estos objetivos en: http://www.ibm.com/certify/tests/.

Prerrequisitos

Para comprender los conceptos descritos en este tutorial, usted ya debe contar con conocimientos sobre conceptos básicos de bases de datos y entender los recursos de seguridad de sistemas operativos.

Requisitos de sistema

Los ejemplos de este tutorial son específicos para DB2 9 ejecutándose en un sistema® operativo Windows (con recursos de seguridad nativos). No obstante, los conceptos y la información proporcionada son relevantes para DB2 ejecutándose en cualquier plataforma distribuida.

Usted no necesita tener una copia DB2 9 para completar este tutorial. No obstante, aprovechará mejor el tutorial si descarga la versión gratuita de prueba IBM DB2 9 para trabajar junto con este tutorial.

Configuración

Para completar los pasos de este tutorial usted debe:

  1. Estar en sesión activa en un computador Windows, como usuario que sea miembro del grupo de Administradores. En los ejemplos de este tutorial, estaremos en sesión activa con el ID de usuario gmilne.
  2. DB2 9 instalado.
  3. Haber creado un grupo nuevo en la máquina en la que se instaló el DB2. En este tutorial, se usa el ID de grupo db2grp1 .
  4. Haber creado un segundo ID de usuario en la máquina en la que se instaló en DB2. En este tutorial, para este propósito usaremos el ID de usuario test1. Note que el usuario test1 no es miembro del grupo de Administradores.

Seguridad DB2

Aspectos de la seguridad de base de datos

La seguridad de bases de datos es de extrema importancia actualmente. Su base de datos puede permitir a los clientes comprar productos en Internet, o puede contener datos históricos usados para predecir tendencias de negocios; en cualquier caso, su compañía necesita un plan de seguridad sólido para su base de datos.

Un plan de seguridad para base de datos debe definir:

  • Quién tiene permitido el acceso a la instancia y/o base de datos
  • Dónde y cómo se verificará la contraseña de un usuario
  • El nivel de autoridad que se concede a un usuario
  • Los comandos que tiene permitido ejecutar un usuario
  • Los datos que un usuario tiene permitido leer y/o alterar
  • Los objetos de base de datos que un usuario tiene permitido crear, alterar y/o descartar

Mecanismos de seguridad DB2

Existen tres mecanismos principales dentro de DB2 que permiten a un DBA implementar un plan de seguridad de base de datos: autenticación, autoridad y privilegios.

La autenticación es el primer recurso de seguridad que usted encontrará cuando intente acceder a una instancia o base de datos DB2. La autenticación DB2 funciona muy de cerca con los recursos de seguridad del sistema operativo subyacente para verificar los ID y contraseñas de usuario. DB2 también puede trabajar con protocolos de seguridad como Kerberos para autenticar usuarios.

La autoridad involucra determinar las operaciones que los usuarios y/o grupos pueden efectuar y los objetos de datos a los que pueden acceder. La capacidad de un usuario para efectuar operaciones de alto nivel de administración de base de datos y de instancia, está determinada por las autoridades que se le hayan asignado. Existen cinco niveles de seguridad diferentes dentro de DB2 que son SYSADM, SYSCTRL, SYSMAINT, DBADM y LOAD.

Los privilegios son un poco más granulares que las autoridades, y pueden asignarse a usuarios y/o grupos. Los privilegios ayudan a definir los objetos que un usuario puede crear o descartar. Estos también definen los comandos que un usuario puede usar para acceder a objetos como tablas, vistas índices y paquetes. En el DB2 9 es nuevo el concepto de control de acceso basado en etiquetas (LBAC), el cual permite un control más granular sobre quién puede acceder a filas y/o columnas individuales.

Para prepararse para la siguiente sección del tutorial, usted necesita crear bases de datos dentro de una instancia DB2. Asegúrese de que la variable %DB2INSTANCE% todavía esté definida para DB2, y luego cree la base de datos de muestra usando el comando db2sampl unidad, usando el nombre de la unidad donde desee crear la muestra. Para los ejemplos de este tutorial, usted creará la base de datos de muestra en su unidad D:, así:

D:\SQLLIB\BIN> db2sampl d:

Clientes, servidores, gateways y hosts

Es particularmente importante que usted entienda los términos cliente, servidor, gateway y host cuando esté considerando la seguridad de todo el entorno de base de datos. Con frecuencia un entorno de base de datos consiste de varias máquinas diferentes; usted debe salvaguardar la base de datos y cualquier punto potencial de acceso a datos. Los conceptos de clientes, servidores, gateways y hosts son particularmente importantes cuando se está tratando con la autenticación en DB2.

El siguiente diagrama ilustra una configuración básica cliente-servidor-host.

Figura 1. Configuración básica cliente-servidor-host

El servidor de base de datos es la máquina (o máquinas de un sistema de bases de datos particionadas) en donde reside físicamente la base de datos. Los clientes de base de datos DB2 son máquinas que están configuradas para ejecutar consultas contra la base de datos que está en el servidor. Estos clientes pueden ser locales (residen en la misma máquina física que el servidor de base de datos) o pueden ser remotos (residen en máquinas separadas).

Si la base de datos reside en una máquina de sistema principal que se ejecute en un sistema operativo como AS/400® (iSeries®) o OS/390® (zSeries®), se llama un host o servidor host. Una gateway es una máquina que ejecuta el producto DB2 Connect. Mediante el gateway, las máquinas cliente DB2 pueden conectarse a una base de datos DB2 que resida en la máquina host. A el gateway también se le conoce como el DB2 Connect Server. Los sistemas con el producto Enterprise Server Edition instalado también tienen integrada la funcionalidad DB2 Connect.


Autenticación DB2

Cuándo autentica DB2

La autenticación DB2 controla los siguientes aspectos del plan de seguridad de base de datos:

  • Quién tiene permitido el acceso a la instancia y/o base de datos
  • Dónde y cómo se verificará la contraseña de un usuario

Esto lo hace con la ayuda de los recursos de seguridad del sistema operativo subyacente cada vez que se emite un comando attach o connect . Los comandos attach se usan para conectar la instancia DB2, mientras que los comandos connect se usan para conectarse a una base de datos dentro de una instancia DB2. Los siguientes ejemplos le muestran las diferentes formas en que DB2 autenticará al usuario que esté emitiendo estos comandos. Estos ejemplos usan el tipo de autenticación predeterminado de tipo SERVER del archivo de configuración de gestor de base de datos. El ejemplo 3 a continuación ilustra cómo se puede usar DB2 para cambiar la contraseña del OS del servidor.

Inicie sesión en la máquina donde está instalado DB2 con el ID de usuario que usó para crear la instancia DB2. Emita los siguientes comandos:

db2 attach to DB2

Aquí la autenticación se hace de forma implícita. El ID de usuario usado para iniciar sesión en la máquina se utiliza y se asume que ya ha sido verificado por el sistema operativo.

db2 connect to sample user test1 using password
Database Connection Information
Database server        = DB2/NT 9.1.0
SQL authorization ID   = TEST1
Local database alias   = SAMPLE

Aquí la autenticación se hace de forma explícita. El usuario test1 con contraseña password es verificado por el sistema operativo. Usertest1 is successfully connected to the sample database.

db2 connect to sample user test1 using password new chgpass confirm chgpass

El ID de usuario test1 con contraseña password es verificado por el sistema operativo como en el ejemplo 2. Luego la contraseña para test1 es cambiada por el sistema operativo, de password a chgpass. como resultado, el comando del ejemplo 2 fallará si lo vuelve a emitir.

Tipos de autenticación DB2

Los tipos de autenticación son usados por DB2 para determinar dónde tendrá lugar la autenticación. Por ejemplo, en un entorno de cliente-servidor, ¿el cliente o la máquina de servidor verificarán el ID y la contraseña del usuario? En un entorno de cliente-gateway-host, ¿el cliente o la máquina host verificarán el ID y la contraseña?

DB2 9 tiene la capacidad para especificar diferentes mecanismos de autenticación dependiendo de si el usuario está intentando conectarse con la base de datos o efectuar acoples de instancia y operaciones de nivel de instancia. De forma predeterminada, la instancia se configura para que use un tipo de autenticación para todas las solicitudes de nivel de instancia y de nivel de conexión. Esto es especificado por el parámetro AUTHENTICATION del Database Manager Configuration. Introducido en la V9.1, es el parámetro SRVCON_AUTH del Database Manager Configuration. Este parámetro trata específicamente con conexiones con bases de datos. Así, por ejemplo, si usted tiene el siguiente conjunto en su DBM CFG:

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

Luego los acoples a la instancia utilizarán SERVER_ENCRYPT. No, obstante, las conexiones con la base de datos utilizarán autenticación KERBEROS. Si KERBEROS no fue inicializado adecuadamente para el servidor pero se suministró un ID/contraseña de usuario válidos, entonces al usuario se le permitirá acoplarse a la instancia, pero no se le permitirá conectarse a la base de datos.

La siguiente tabla resume los tipos de autenticación DB2 disponibles. En un entorno cliente-gateway-host, estas opciones de autenticación se establecen en el cliente y el gateway, no en la máquina host. A lo largo de esta sección se discute en más detalle cómo configurar estas opciones. Consulte Clientes, servidores, gateways, y hosts como recordatorio.

Tabla 1. Tipos de autenticación DB2

TipoDescripción
SERVER La autenticación se lleva a cabo en el servidor.
SERVER_ENCRYPT La autenticación se lleva a cabo en el servidor. Las contraseñas son cifradas en la máquina cliente antes de ser enviadas al servidor.
CLIENT La autenticación se lleva a cabo en la máquina cliente (vea Manejando clientes no confiables para excepciones).
*KERBEROS La autenticación es llevada a cabo por el software de seguridad Kerberos.
*KRB_SERVER_ENCRYPT La autenticación es llevada a cabo por el software de seguridad Kerberos si la configuración de cliente es KERBEROS. En caso contrario, se utiliza SERVER_ENCRYPT.
DATA_ENCRYPT La autenticación se lleva a cabo en el servidor. El servidor acepta el ID y las contraseñas cifradas del usuario y descifra los datos. Esto funciona de la misma forma que SERVER_ENCRYPT, excepto que los datos también son cifrados.
DATA_ENCRYPT_CMP La autenticación es la misma que para DATA_ENCRYPT, excepto que este esquema permite que clientes antiguos que el esquema DATA_ENCRYPT no permite, se conecten usando autenticación SERVER_ENCRYPT. En este caso los datos no serán cifrados. Si el cliente que se está conectando soporta DATA_ENCRYPT, es forzado a cifrar los datos y no puede pasarse a autenticación SERVER_ENCRYPT. Esta autenticación solo es válida en el archivo de configuración de gestor de base de datos del servidor y no es válido cuando se usa con el comando CATALOG DATABASE en una instancia de cliente o de gateway.
GSSPLUGIN La autenticación es controlada por un plug-in GSS-API externo.
GSS_SERVER_ENCRYPT La autenticación es controlada por un plug-in GSS-API externo. en el caso que el cliente no soporte alguno de los plug-in GSS-API del servidor, se utiliza autenticación SERVER_ENCRYPT.

*Estas configuraciones solo son válidas para sistemas operativos Windows 2000®, AIX®, Solaris y Linux® .

Configurando la autenticación en el servidor

La autenticación se establece en el servidor de base de datos dentro del archivo Database Manager Configuration (DBM CFG), usando el parámetro AUTHENTICATION. Recuerdo, el archivo DBM CFG es un archivo de configuración de nivel de instancia. Así, el parámetro AUTHENTICATION afecta a todas las bases de datos dentro de la instancia. Los siguientes comandos muestran cómo se puede alterar este parámetro.

Para ver el parámetro de autenticación en el archivo de configuración:

db2 get dbm cfg

Para alterar el parámetro de autenticación a server_encrypt:

C:\PROGRA~1\SQLLIB\BIN> db2 update dbm cfg using authentication server_encrypt
C:\PROGRA~1\SQLLIB\BIN> db2stop
C:\PROGRA~1\SQLLIB\BIN> db2start

Ciertos tipos de autenticación como GSSPLUGIN, KERBEROS y CLIENT requieren la configuración de otros parámetros de Database Manager Configuration, como TRUST_ALLCLNTS, SRV_PLUGIN_MODE y SRVCON_PW_PLUGIN. Más adelante hay más detalles sobre estas configuraciones.

Configurando la autenticación en el gateway

En el gateway la autenticación se establece usando el comando de base de datos de catálogo. Para estos ejemplos, usaremos una base de datos de muestra llamada myhostdb.

Para establecer el tipo de autenticación de gateway en SERVER, usted emite el siguiente comando en la máquina gateway:

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

Note que la autenticación nunca se efectúa en el gateway misma. En DB2 Versión 8, la autenticación siempre debe ocurrir en el cliente o en el servidor de base de datos host.

Configurando la autenticación en el cliente

Consideremos dos escenarios en dos máquinas cliente separadas. Vamos a configurar una para que se conecte a una base de datos en una máquina de servidor (DB2 UDB LUW plataforma distribuida), y la otra para que se conecte a una base de datos en una máquina host (por ejemplo, DB2 for zSeries).

  • Cliente conectándose a una base de datos de servidor: La configuración de autenticación en la entrada de directorio de base de datos para la base de datos que se está conectando debe coincidir con el servidor de base de datos (con excepción de KRB_SERVER_ENCRYPT, DATA_ENCRYPT_CMP, y GSS_SERVER_ENCRYPT).

    Supongamos que el tipo de autenticación de servidor está en SERVER. Entonces se emitirá el siguiente comando en el cliente para catalogar la base de datos de servidor llamada sample:

    db2 catalog database sample at node nd1 authentication SERVER

    Si no se especifica el tipo de autenticación, el cliente intentará usar SERVER_ENCRYPT de forma predeterminada.
  • Cliente conectándose a una base de datos host: Supongamos que el tipo de autenticación de lo gateway está en SERVER. Si no se especifica un tipo de autenticación, se asume autenticación SERVER_ENCRYPT cuando se esté accediendo a la base de datos mediante DB2 Connect. La autenticación se llevará a cabo en el servidor de base de datos host. El siguiente comando emitido desde el cliente causará que el cliente envíe IDs de usuario y contraseñas sin cifrar a la gateway:
    db2 catalog database myhostdb at node nd1 authentication SERVER

    Ahora supongamos que la autenticación se establece como SERVER_ENCRYPT en el gateway. La autenticación se llevará a cabo nuevamente en el servidor de base de datos host. El ID de usuario y contraseña son cifrados en el gateway entes de ser enviados a la máquina host. Esta es la conducta predeterminada.

Manejando clientes no confiables

Si la máquina de servidor o de gateway tienen la autenticación en CLIENT, esto implica que se espera que el cliente autentique el ID y la contraseña del usuario. Sin embargo, algunas máquinas de cliente no tienen sistemas operativos con recursos de seguridad nativos. Tales clientes no confiables incluyen clientes DB2 ejecutándose en Windows 98® y Windows ME®. DB2 V9.1 no soporta Windows 98 ni Windows ME, pero soporta clientes de nivel inferior por lo cual aún puede tener que tratar con clientes no confiables V8.

Hay dos parámetros adicionales en el archivo DBM CFG para determinar dónde debe darse la autenticación cuando el método de autenticación de servidor o de gateway está en CLIENT y hay clientes no confiables intentando conectarse a la base de datos o acoplarse a la instancia DB2. Estos son los parámetros TRUST_ALLCLNTS y TRUST_CLNTAUTH.

Cuando el tipo de autenticación del servidor o el gateway es CLIENT, hay otros dos factores que entran en juego además de los parámetros TRUST_ALLCLNTS y TRUST_CLNTAUTH. El primero es si se suministraron un ID y contraseña de usuario explícitamente, y el segundo es el tipo de cliente que se está conectando. Los tres clientes dB2 son:

  • Clientes no confiables: Como se describió arriba
  • Clientes host: Clientes que se están ejecutando en sistemas operativos host, como zSeries
  • Clientes confiables: Clientes que se ejecutan en sistemas operativos que no son host, que tienen recursos de seguridad nativos como Windows NT®, Windows 2000®, Windows 2003®, Windows XP, y todas las formas de UNIX® y Linux.

Cuando la autenticación está configurada en CLIENT

La siguiente tabla resume dónde se llevará a cabo la autenticación cuando cada tipo de cliente emita un comando connect o attach hacia un servidor cuyo tipo de autenticación esté configurado en CLIENT.

Tabla 2. Autenticación tras comando connect o attach

¿Se suministró ID/Contraseña de usuario?TRUST_ALLCLNTS TRUST_CLNTAUTHCliente no confiableCliente confiableCliente host
No YesCLIENTCLIENTCLIENTCLIENT
No YesSERVERCLIENTCLIENTCLIENT
No NoCLIENTSERVERCLIENTCLIENT
No NoSERVERSERVERCLIENTCLIENT
NoDRDAONLYCLIENTSERVERSERVERCLIENT
NoDRDAONLYSERVERSERVERSERVERCLIENT
Yes YesCLIENTCLIENTCLIENTCLIENT
Yes YesSERVERSERVERSERVERSERVER
Yes NoCLIENTSERVERCLIENTCLIENT
Yes NoSERVERSERVERSERVERSERVER
YesDRDAONLYCLIENTSERVERSERVERCLIENT
YesDRDAONLYSERVERSERVERSERVERSERVER

DRDAONLY se refiere a clientes host únicamente, sin importar el hecho de que los clientes DB2 Versión 8 también se conectan usando DRDA.

Los siguientes ejemplos ilustran la configuración de tipos y parámetros de autenticación en servidor y en cliente:

Configurando la autenticación en el servidor:

db2 update dbm cfg using authentication client
db2 update dbm cfg using trust_allclnts yes 
db2 update dbm cfg using trust_clntauth server 
db2stop
db2start

Configurando la autenticación en el cliente:

db2 catalog database sample at node nd1 authentication client

En el ejemplo anterior, si el comando

db2 connect to sample

es emitido desde cualquier cliente, la autenticación se lleva a cabo en el cliente. Si el comando

db2 connect to sample user test1 using password

es emitido desde cualquier cliente, la autenticación se lleva a cabo en el servidor.

Arquitectura de plug-in de seguridad DB2

DB2 V8.2 introdujo el concepto de plug-ins de seguridad para DB2. Este concepto ha sido mejorado aún más en el DB2 V9.1. Usando llamados GSS-API estándar un usuario puede escribir un plug-in de seguridad y pasar el trabajo de autenticación del ID de usuario a un programa de seguridad externo. Un ejemplo de esto es la propia autenticación KERBEROS en DB2. Cuando usted instala DB2 ESE, o el cliente de desarrollo de aplicaciones en una máquina, parte de esa instalación pone código de aplicación de muestra en su instancia de directorio. Si usted observa en el directorio samples\security\plugins podrá ver allí tres ejemplos sobre cómo codificar plug-ins de seguridad. Esta sección describirá el uso de plug-in en la arquitectura de seguridad DB2, pero no cubre cómo codificar o compilar los plug-in en sí. Para una descripción detallada de cómo se hace esto, consulte DB2 UDB Security Part 2: Understand the DB2 Universal Database Security plug-ins.

Autenticación Kerberos

La autenticación Kerberos proporciona a DB2 una forma para autenticar usuarios sin tener que hacer pasar ID ni contraseñas de usuario sobre la red. El protocolo de seguridad Kerberos lleva a cabo autenticación como un servicio de autenticación externo, usando criptografía convencional para crear una clave secreta compartida. Esta clave se convierte en la credencial del usuario y se utiliza para verificar la identidad de los usuarios durante todas las veces que se soliciten servicios de red o locales. El uso del protocolo de seguridad Kerberos permite el uso de inicio único de sesión para un servidor remoto de base de datos DB2.

Primero, vamos a revisar la configuración DB2 para usar autenticación Kerberos. Como se mencionó arriba, la autenticación Kerberos es implementada en DB2 usando la arquitectura de plug-in. El código fuente para el plug-in predeterminado Kerberos se suministra en el directorio samples/security/plugins , llamado IBMkrb5.c. Antes de que la autenticación Kerberos funcione para DB2, Kerberos debe activarse y ser soportado tanto en el cliente como en el servidor. Para que esto funcione, se deben cumplir las siguientes condiciones:

  1. Las máquinas de cliente y servidor deben pertenecer al mismo dominio
  2. Se deben configurar los Principals (ID de usuario en Kerberos) adecuados.
  3. El archivo keytab del servidor debe ser creado y ser legible por el propietario de la instancia.
  4. Todas las máquinas deben tener relojes sincronizados.

Usted puede encontrar más información sobre Kerberos en la documentación que acompaña al producto Kerberos instalado.

Para permitir que DB2 use autenticación KERBEROS usted primero debe decirle al cliente dónde encontrar el plug-in kerberos que usted está usando. En el cliente, ejecute el siguiente comando:

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

En este ejemplo se usa en plug-in KERBEROS predeterminado. Esto puede haber sido modificado por el DBA para efectuar funciones especiales si la implementación Kerberos que se está usando le solicitó hacerlo.

También existe la capacidad para decirle al cliente exactamente contra cuál servidor principal se está autenticando. Esta opción salta el primer paso de autenticación Kerberos en donde el cliente debe descubrir el servidor principal de la instancia a la que se está conectando. El parámetro AUTHENTICATION puede ser especificado cuando se está catalogando la base de datos en el cliente. Su formato es:

DB2 CATALOG DB dbname AT NODE node name AUTHENTICATION KERBEROS TARGET PRINCIPAL
   service/host@REALM

Este paso es opcional.

DB2 CATALOG DB sample AT NODE testnd AUTHENTICATION KERBEROS TARGET PRINCIPAL
   gmilne/gmilne02.torolab.ibm.com@TOROLAB.IBM.COM

El siguiente paso para configurar la autenticación Kerberos es configurar el servidor. El srvcon_gssplugin_list. Este parámetro puede configurarse con una lista de los diferentes plug-in GSS-API soportados, pero a usted solo se le permite un plug-in Kerberos. Si en la lista no hay plug-in Kerberos, se utilizará automáticamente el plug-in pre determinado IBMkrb5. Si usted pretende permitir que toda la autenticación (acoples de instancia así como conexiones de base de datos) usen Kerberos, entonces ejecute lo siguiente:

DB2 UPDATE DBM CFG USING AUTHENTICATION KERBEROS

o

DB2 UPDATE DBM CFG USING AUTHENTICATION KRB_SERVER_ENCRYPT

Si solo desea que DB2 use Kerberos para autenticar las conexiones entrantes de base de datos (y que use SERVER para acoples de instancia entrantes), entonces ejecute lo siguiente:

DB2 UPDATE DBM CFG USING SVRCON_AUTH KERBEROS

o

DB2 UPDATE DBM CFG USING SVRCON_AUTH KRB_SERVER_ENCRYPT

Dependiendo del ancho de bit (32 o 64 bit) de la instancia, DB2 cargará automáticamente el plug-inIBMkrb5 cuando se inicie la instancia.

Otras configuraciones de autenticación

Si usted observa en el DBM CFG para una instancia V9.1, verá varias configuraciones que pueden afectar la forma en que el DB2 autenticará los ID de usuario. Como se mencionó arriba, existen configuraciones para ID de usuario de OS estándar (CLIENT, SERVER, SERVER_ENCRYPT, DATA_ENCRYPT, DATA_ENCRYPT_CMP), así como plug-ins para pasar autenticación a programas externos (KERBEROS, KRB_SERVER_ENCRYPT, GSSPLUGIN, GSS_SERVER_ENCRYPT). Esta sección trata específicamente algunas de las otras variables de configuración que pueden tener un impacto en cómo se autentica a un usuario.

Client Userid-Password Plugin          (CLNT_PW_PLUGIN) =
Group Plugin                             (GROUP_PLUGIN) =
GSS Plugin for Local Authorization    (LOCAL_GSSPLUGIN) =
Server Plugin Mode                    (SRV_PLUGIN_MODE) = UNFENCED
Server List of GSS Plugins      (SRVCON_GSSPLUGIN_LIST) =
Server Userid-Password Plugin        (SRVCON_PW_PLUGIN) =
Cataloging allowed without authority   (CATALOG_NOAUTH) = NO
Bypass federated authentication            (FED_NOAUTH) = NO

En la lista anterior se han removido los parámetros que ya se han tratado.

Tabla 3. Otros parámetros

CLNT_PW_PLUGINEste parámetro es especificado en el DBM CFG del lado del cliente. Este especifica el nombre del plug-in de cliente usado para autenticación de cliente y local.
GROUP_PLUGINEl predeterminado de este valor es en blanco (NULL). Configurar este al nombre del plug-in definido por el usuario invocará ese plug-in para toda la enumeración de grupo en lugar de depender de la búsqueda de grupo del sistema operativo. Esto está vinculado con las secciones de autoridad que se tratan más adelante.
LOCAL_GSSPLUGINEste parámetro especifica el nombre de la biblioteca de plug-in GSS API a ser usada para autorización local de nivel de instancia cuando el valor del parámetro de autenticación de configuración del gestor de base de datos sea GSSPLUGIN o GSS_SERVER_ENCRYPT.
SRV_PLUGIN_MODE(YES/NO) El valor predeterminado para este parámetro es NO. Cuando se cambia a YES, los plug-in GSS-API usados se inician en modo FENCED, de forma similar a la manera en que funcionan los procedimientos almacenados FENCED. Un plug-in FENCED que falle no puede hacer que la instancia DB2 también falle. Mientras se desarrollan los plug-in, se recomienda que los ejecute en modo fenced para que los problemas lógicos y las fugas de memoria de esos plug-in no hagan fallar la instancia. En cuanto se determina que el plug-in es seguro, se debe ejecutar unfenced por razones de desempeño.
SRVCON_GSSPLUGIN_LISTSe utiliza una lista de plug-ins que el gestor de la base de datos del servidor utilizará durante la autenticación, con KERBEROS o con KRB_SERVER_ENCRYPT, GSSPLUGIN, o GSS_SERVER_ENCRYPT. Cada plug-in de la lista deberá estar separado por una coma (',') y sin espacios intermedios. Los plug-in se listan en orden de preferencia, donde el primero de la lista se usa primero para intentar autenticar el ID / contraseña de usuario enviados. Solo cuando todos los plug-in enviados hayan retornado un error DB2 retornará un error de autenticación al usuario.
SRVCON_PW_PLUGINEste parámetro permite al usuario cambiar la autenticación predeterminada que usa DB2 para verificad ID y contraseñas de usuario cuando se especifican autenticaciones CLIENT, SERVER, o SERVER_ENCRYPT. De forma predeterminada, su valor es NULL y se utilizan los métodos DB2 predeterminados.
CATALOG_NOAUTH(YES/NO) Predeterminado en NO. Cambiar este parámetro a YES permite a los usuarios que no están verificados para ser miembros de los grupos SYSADM, SYSCTRL o SYSMAINT, cambiar los catálogos Database, Node, Admin y DCS de la máquina. Esto solo es útil en escenarios de cliente donde el usuario que inició sesión en la máquina está usando un cliente no confiable (definido arriba) o ha iniciado sesión con un ID de usuario que no tiene permitido conectarse a la base de datos o acoplarse a la instancia, pero debe catalogar entradas en la máquina cliente.
FED_NOAUTHCuando fed_noauth esté en yes, la autenticación se configura en server o server_encrypt, federated si está en yes, entonces se salta la autenticación en la instancia. Se sume que la autenticación sucederá en la fuente de datos. Tenga cuidado cuando fed_noauth esté en yes. La autenticación no se efectúa ni en el cliente ni en DB2. Cualquier usuario que conozca el nombre de autenticación SYSADM puede asumir autoridad SYSADM para el servidor federado.

Autoridades DB2

Introducción a las autoridades

La autoridades DB2 controlan los siguientes aspectos del plan de seguridad de base de datos:

  • El nivel de autoridad que se le concede a un usuario
  • Los comandos que tiene permitido ejecutar un usuario
  • Los datos que un usuario tiene permitido leer y/o alterar
  • Los objetos de base de datos que un usuario tiene permitido crear, alterar y/o descartar

Las autoridades están compuestas por grupos de privilegios y de operaciones de alto nivel, de mantenimiento y herramientas de gestor de base de datos (nivel de instancia). De las cinco autoridades disponibles en DB2, SYSADM, SYSCTRL, SYSMAINT, y SYSMON son autoridades de nivel de instancia. Eso significa que su alcance incluye comandos de nivel de instancia, así como comandos contra todas las bases de datos dentro de la instancia. Estas autoridades solo pueden ser asignadas a un grupo; usted puede hacer lo mediante el archivo DBM CFG.

Las autoridades DBADM, LOAD y SECADM se asignan a grupos o usuarios para bases de datos particulares. Esto se puede hacer de forma explícita usando el comando GRANT .

Las siguientes secciones describen cómo se asigna cada autoridad y cuáles comandos pueden ejecutar los usuarios con esa autoridad. Note que cualquier referencia a membresía de grupo implica que los nombres de usuario y de grupo ya han sido definidos a nivel de sistema operativo.

Los usuarios pueden determinar cuáles autoridades y privilegios de nivel de base de datos tienen al emitir el siguiente comando:

db2 get authorizations

Obteniendo autoridad SYSADM

La autoridad SYSADM en DB2 es comparable a la autoridad raíz UNIX o a la autoridad de Administrador en Windows. Los usuarios con autoridad SYSADM para una instancia DB2 pueden ejecutar cualquier comando DB2 contra esa instancia, cualquier base de datos dentro de la instancia y cualquier objeto dentro de esas bases de datos. Estos también tienen la capacidad para acceder a datos dentro de la base de datos y a conceder o revocar privilegios y autoridades. Los usuarios SYSADM son los únicos usuarios a los que se les permite actualizar el archivo DBM CFG.

La autoridad SYSADM es controlada en el archivo DBM CFG mediante el parámetro SYSADM_GROUP. Cuando se crea la instancia, este parámetro se configura a Administrador en Windows (aunque aparece en blanco si usted emite el comando db2 get dbm cfg ). En UNIX, se establece para que sea el grupo principal del usuario que creó la instancia.

Como los usuarios SYSADM son los únicos usuarios a los que se les permite actualizar el archivo DBM CFG, también son los únicos que tienen permitido conceder cualquiera de las autoridad SYS* a otros grupos. El siguiente ejemplo ilustra cómo conceder una autoridad SYSADM al grupo db2grp1:

 db2 update dbm cfg using SYSADM_GROUP db2grp1

Recuerde, este cambio no tendrá efecto sino hasta que la instancia se detenga y se reinicie. Tenga en cuenta también que si usted actualmente no está en sesión activa como miembro dedb2grp1, ¡tal vez no tenga autoridad para reiniciar la instancia! Es posible que tenga que cerrar sesión y volver a iniciarla con un ID del grupo correcto, o añadir su ID actual a db2grp1.

Obteniendo autoridad SYSCTRL

Los usuarios con autoridad SYSCTRL pueden ejecutar todos los comandos administrativos y de mantenimiento dentro de la instancia. No obstante, a diferencia de los usuarios SYSADM, estos no pueden acceder a ningún dato de las bases de datos, a menos que se les concedan los privilegios para hacerlo. Algunos ejemplos de comandos que puede ejecutar un usuario SYSCTRL contra cualquier base de datos de una instancia son:

  • db2start/db2stop
  • db2 create/drop database
  • db2 create/drop tablespace
  • db2 backup/restore/rollforward database
  • db2 runstats (contra cualquier tabla)
  • db2 update db cfg for database dbname

Un usuario con autoridad SYSADM puede asignar SYSCTRL a un grupo usando el siguiente comando:

db2 update dbm cfg using SYSCTRL_GROUP nombre de grupo

Obteniendo la autoridad SYSMAINT

Los comandos que puede ejecutar un usuario con la autoridad SYSMAINT son un subconjunto de los permitidos a los usuarios con la autoridad SYSCTRL. Los usuarios SYSMAINT solo pueden ejecutar tareas de mantenimiento como:

  • db2start/db2stop
  • db2 backup/restore/rollforward database
  • db2 runstats (contra cualquier tabla)
  • db2 update db cfg for database dbname

Note que los usuarios con SYSMAINT no pueden crear ni descartar bases de datos ni espacios de tabla. Tampoco pueden acceder a ningún dato de las bases de datos, a menos que se les concedan los privilegios para hacerlo.

Si usted tiene autoridad SYSADM, puede asignar autoridad SYSMAINT a un grupo usando el siguiente comando:

db2 update dbm cfg using SYSMAINT_GROUP nombre de grupo

Obteniendo autoridad SYSMON

La autoridad SYSMON proporciona la capacidad para tomar capturas instantáneas de supervisión de sistema de base de datos, de una instancia de gestor de base de datos o de sus bases de datos. La autoridad SYSMON está asignada al grupo especificado por el parámetro de configuración sysmon_group . Si se especifica un grupo, la membresía a ese grupo es controlada por fuera del gestor de base de datos mediante el recurso de seguridad usado por su plataforma.

La autoridad SYSMON le permite al usuario ejecutar los siguientes comandos:

  • GET DATABASE MANAGER MONITOR SWITCHES
  • GET MONITOR SWITCHES
  • GET SNAPSHOT
  • LIST ACTIVE DATABASES
  • LIST APPLICATIONS
  • LIST DCS APPLICATIONS
  • RESET MONITOR
  • UPDATE MONITOR SWITCHES

La autoridad SYSMON le permite al usuario usar las siguientes API:

  • db2GetSnapshot - Tomar captura instantánea
  • db2GetSnapshotSize - Estimar el tamaño requerido para db2GetSnapshot() almacenamiento intermedio de salida
  • db2MonitorSwitches - Obtener/actualizar conmutadores de monitor
  • db2ResetMonitor - Reiniciar el monitor

La autoridad SYSMON le permite al usuario usar todas las funciones de captura instantánea de tabla SQL sin ejecutar previamente SYSPROC.SNAP_WRITE_FILE. SYSPROC.SNAP_WRITE_FILE realiza una captura instantánea y guarda su contenido en un archivo. Si se llama a cualquier función de tabla de captura instantánea con parámetros de entrada nulos, se retorna el contenido del archivo en lugar de una captura instantánea en tiempo real.

Los usuarios con los niveles de autoridad SYSADM, SYSCTRL o SYSMAINT también poseen autoridad SYSMON.

Un usuario con autoridad SYSADM puede asignar SYSMON a un grupo usando el siguiente comando:

db2 update dbm cfg using SYSMON_GROUP group name

Obteniendo autoridad DBADM

La autoridad DBADM es una autoridad de nivel de base de datos más que una autoridad de nivel de instancia. Resumiendo, los usuarios DBADM tiene control total sobre una base de datos (casi). Los usuarios DBADM no pueden efectuar tareas administrativas o de mantenimiento como:

  • drop database
  • drop/create tablespace
  • backup/restore database
  • update db cfg for database nombre de db

Sin embargo, pueden efectuar las siguientes tareas:

  • db2 create/drop table
  • db2 grant/revoke (cualquier privilegio)
  • db2 runstats (cualquier tabla)

A los usuarios DBADM también se les conceden automáticamente todos los privilegios para los objetos de base de datos y sus contenidos. Como la autoridad DBADM es una autoridad de nivel de base de datos, puede asignarse tanto a usuarios como a grupos. Los siguientes comandos ilustran diferentes formas en las que usted puede conceder autoridad DBADM.

  • db2 create database test

    Este comando da autoridad DBADM implícita sobre la base de datos llamada test al usuario que emitió el comando.

  • db2 connect to sample
    db2 grant dbadm on database to user tst1

    Este comando solo puede ser emitido por usuarios SYSADM; este concede la autoridad DBADM al usuario tst1 de la base de datos de muestra. Note que el usuario que lo emite debe estar conectado a la base de datos de muestra para que se conceda la autoridad DBADM.

  • db2 grant dbadm on database to group db2grp1

    Este comando concede la autoridad DBADM a todos los del grupo db2grp1. De nuevo, solo los usuarios SYSADM pueden emitir este comando.

Obteniendo la autoridad LOAD

La autoridad LOAD también se considera una autoridad de nivel de base de datos y por lo tanto puede concederse a usuarios y a grupos. Como su nombre lo indica, la autoridad LOAD autoriza a los usuarios a emitir el comando LOAD contra una tabla. El comando LOAD se utiliza normalmente como una alternativa más rápida que los comandos insert o import cuando se está llenando una tabla con grandes cantidades de datos. Dependiendo del tipo de LOAD que desee ejecutar, tener solo la autoridad LOAD no es suficiente. También pueden llegar a requerirse privilegios específicos sobre la tabla.

Los siguientes comandos pueden ser ejecutados por usuarios con la autoridad LOAD:

  • db2 quiesce tablespaces for table
  • db2 list tablespaces
  • db2 runstats (cualquier tabla)
  • db2 load insert (debe tener privilegios para insert sobre la tabla)
  • db2 load restart/terminate after load insert (debe tener privilegios para insert sobre la tabla)
  • db2 load replace (debe tener privilegios insert y delete sobre la tabla)
  • db2 load restart/terminate after load replace (debe tener privilegios insert y delete sobre la tabla)

Solo los usuarios con autoridad SYSADM o DBADM tienen permitido conceder o revocar autoridad LOAD para usuarios o grupos. Los siguientes ejemplos ilustran cómo la autoridad LOAD puede permitir al usuario LOAD datos a una tabla llamada sales. Suponga que el comando db2 connect to sample ya se ha ejecutado.

  • db2 grant load on database to user tst1
    db2 grant insert on table sales to user tst1

    Con la autoridad LOAD y el privilegio insert, tst1 pudo emitir un LOAD INSERT o un LOAD RESTART, o TERMINATE después de un LOAD INSERT contra la tabla sales.

  • db2 grant load on database to group grp1
    db2 grant delete on table sales to group grp1
    db2 grant insert on table sales to group grp1

    Con la autoridad LOAD y con los privilegios delete e insert, cualquier miembro de grp1 puede emitir un LOAD REPLACE o un LOAD RESTART, o TERMINATE después de un LOAD REPLACE contra la tabla sales.

Obteniendo autoridad SECADM

La autoridad SECADM es considerada una autoridad de nivel de base de datos, pero solo puede ser concedida a un usuario específico por un usuario SYSADM. Un usuario con SECADM puede hacer lo siguiente:

  • Crear y descartar componentes de etiqueta de seguridad
  • Crear y descartar políticas de seguridad
  • Crear y descartar etiquetas de seguridad
  • Conceder y revocar etiquetas de seguridad
  • Conceder y revocar exenciones de reglas LBAC
  • Conceder y revocar privilegios setsessionuser
  • Ejecutar el enunciado SQL TRANSFER OWNERSHIP sobre objetos que usted no posee

Ningún otro usuario puede ejecutar estas funciones, ni siquiera SYSADM, a menos que SECADM haya sido otorgado explícitamente a ese usuario SYSADM. Esto es muy importante porque estas capacidades de seguridad son bastante potentes y solo se deben conceder a usuarios que estén definidos como administradores de seguridad. Vea la sección "Control de acceso basado en etiquetas" para más información sobre este nuevo recurso de seguridad en DB2 V9.


Privilegios DB2

Privilegios de base de datos y de objeto

En la sección anterior se tocó brevemente el concepto de privilegios. Los privilegios se pueden ubicar generalmente en dos categorías principales: privilegios de nivel de base de datos, los cuales abarcan todos los objetos de una base de datos, y privilegios de nivel de objeto los cuales están asociados a un objeto específico.

Los privilegios de nivel de base de datos que se le pueden otorgar a un usuario son:

  • CREATETAB: Los usuarios pueden crear tablas dentro de una base de datos.
  • BINDADD: Los usuarios pueden crear paquetes en la base de datos usando el comando BIND.
  • CONNECT: Los usuarios pueden conectarse a la base de datos.
  • CREATE_NOT_FENCED: Los usuarios pueden crear funciones unfenced definidas por usuario (UDF).
  • IMPLICIT_SCHEMA: Los usuarios pueden crear esquemas de forma implícita dentro de la base de datos, sin usar el comando CREATE SCHEMA.
  • LOAD: los usuarios pueden cargar datos a una base de datos
  • QUIESCE_CONNECT: Los usuarios pueden acceder a una base de datos mientras esté en su estado de desactivación temporal.
  • CREATE_EXTERNAL_ROUTINE: Los usuarios pueden crear un procedimiento para que sea usado por aplicaciones y por otros usuarios de la base de datos.

Losobjetos de base de datos incluyen tablas, vistas, índices, esquemas y paquetes. afortunadamente, la mayoría de privilegios de nivel de objeto se explican por sí mismos. La siguiente tabla resume estos privilegios.

Tabla 4. Resumen de privilegios

Nombre del privilegioObjetos relevantesDescripción
CONTROL Tabla, Vista, Índices, Paquetes, Alias, Tipo Distintivo, Función definida por usuario, Secuencia Proporciona autoridad completa sobre el objeto. Los usuarios con este privilegio también pueden conceder o revocar privilegios sobre el objeto para otros usuarios.
DELETE Tabla, Vista Permite a los usuarios eliminar registros del objeto.
INSERT Tabla, Vista Permite a los usuarios insertar registros en el objeto mediante los comandos INSERT e IMPORT.
SELECT Tabla, Vista Proporciona a los usuarios la capacidad de ver el contenido del objeto usando el enunciado select.
UPDATE Tabla, Vista Permite a los usuarios modificar registros dentro de un objeto usando el enunciado update.
ALTER Tabla Permite a los usuarios alterar la definición del objeto usando el enunciado alter.
INDEX Tabla Permite a los usuarios crear índices sobre el objeto usando el enunciado index.
REFERENCES Tabla Proporciona a los usuarios la capacidad para crear y descartar restricción de claves foráneas sobre el objeto.
BIND Paquete Permite a los usuarios volver a vincular paquetes.
EXECUTE Paquete, Procedimiento, Función, Método Permite a los usuarios ejecutar paquetes y rutinas.
ALTERIN Esquema Permite a los usuarios modificar definiciones de objetos dentro del esquema.
CREATEIN Esquema Permite a los usuarios crear objetos dentro del esquema.
DROPIN Esquema Permite a los usuarios descartar objetos del esquema.

En las vistas del catálogo de sistema hay información almacenada sobre privilegios de nivel de objeto. Los nombres de las vistas son syscat.tabauth, syscat.colauth, syscat.indexauth, syscat.schemaauth, syscat.routineauth y syscat.packageauth.

Privilegios explícitos

Los privilegios se pueden conceder y revocar de forma explícita a usuarios o grupos, usando los comandos GRANT o REVOKE. Observemos cómo puede usted utilizar estos comandos sobre varios objetos.

Mientras esté en sesión activa con autoridad de Administrador en Windows, abra dos ventanas de comandos DB2. Asegúrese de que la variable db2instance esté en DB2 ¡en ambas ventanas!

Desde la Ventana 1, emita el siguiente comando:

db2 connect to sample

Ahora, desde la Ventana 2, emita el siguiente comando:

db2 connect to sample user test1 using password

Recuerde, los comandos de la Ventana 1 están siendo emitidos por un usuario con autoridad SYSADM. Los comandos de la Ventana 2 están siendo emitidos por tst1, un usuario sin autoridad ni privilegios específicos en la base de datos de muestra. Note que el nombre de esquema asociado con las tablas de su base de datos de muestra será el nombre del usuario que emitió el comando db2sampl . En estos ejemplos, ese usuario es GMILNE.

Ahora, desde la Ventana 2, emita el siguiente comando:

db2 select * from gmilne.org

Deberá ver esta respuesta:

SQL0551N  "TEST1" does not have the privilege to perform operation "SELECT" 
on object "GMILNE.ORG".

Para corregir la situación, emita el siguiente comando desde la Ventana 1:

db2 grant select on table gmilne.org to user test1

Ahora ¡el comando anterior tendrá éxito! Luego, emita un comando más ambicioso desde la Ventana 2:

db2 insert into gmilne.org values (100, 'Tutorial', 1, 'Eastern', 'Toronto')

De nuevo, verá un mensaje de error:

SQL0551N  "TEST1" does not have the privilege to perform operation  "INSERT" 
on object "GMILNE.ORG"

Entonces, ingrese el siguiente comando desde la Ventana 1:

db2 grant insert on table gmilne.org to group db2grp1

El comando INSERT que falló antes, ahora se debe poder completar exitosamente porque test1 e s un miembro del grupodb2grp1.

Ahora ingrese el siguiente comando en la Ventana 2:

db2 drop table gmilne.emp_photo

De nuevo, verá un mensaje de error:

SQL0551N  "TEST1" does not have the privilege to perform operation "DROP TABLE"
on object "GMILNE.EMP_PHOTO".

Así, vamos a conceder el privilegio. Ingrese lo siguiente desde la Ventana 1:

db2 grant dropin on schema gmilne to all

El comando DROP TABLE debe completarse ahora satisfactoriamente.

Ahora que hemos terminado nuestro ejemplo, vamos a revocar todos los privilegios que acaba de conceder. Hágalo emitiendo los siguientes comandos desde la Ventana 1:

db2 revoke select on table gmilne.org from user test1
db2 revoke insert on table gmilne.org from group db2grp1
db2 revoke dropin on schema gmilne from all

Note que revocar los privilegios de un grupo no necesariamente los revoca para todos los miembros de ese grupo. Por ejemplo, el siguiente comando pudo haberse usado para revocar todos los privilegios (excepto CONTROL) de db2grp1 en la tabla gmilne.org:

db2 revoke all on table gmilne.org from group db2grp1

Sin embargo, el usuario test1 (que es miembro de db2grp1 ) habrá conservado seleccionados los privilegios en esa tabla, dado que se le ha concedido el privilegio directamente.

Privilegios Implícitos

DB2 puede conceder privilegios automáticamente cuando se emiten ciertos comandos, sin necesidad de que se emita un enunciado GRANT explícito, como vio previamente. La siguiente tabla resume algunos comandos que dan como resultado privilegios que están siendo concedidos implícitamente por el gestor de base de datos. Note que estos privilegios son revocados implícitamente cuando se descarta el objeto creado. No obstante, estos no son revocados cuando se revocan explícitamente privilegios de nivel superior.

Tabla 5. Comandos resultantes de privilegios que están siendo concedidos implícitamente por el gestor de base de datos

Comando emitidoPrivilegio concedidoA quién se le concede el privilegio
CREATE TABLE mytable CONTROL en mytable Usuario emitiendo el comando
CREATE SCHEMA myschema CREATEIN, ALTERIN, DROPIN en myschema, más la capacidad de conceder estos a otros Usuario emitiendo el comando
CREATE VIEW myview CONTROL en myview solo si CONTROL se mantiene en todas la tablas y vistas referenciadas en la definición de myview Usuario emitiendo el comando
CREATE DATABASE mydb SELECT en tablas de catálogo de sistema de mydb , IMPLICIT_SCHEMA en mydb * PUBLIC**

*Cuando un usuario crea una base de datos, a ese usuario se le concede autoridad DBADM implícitamente sobre esa base de datos. Con la autoridad DBADM se incluyen los privilegios CONNECT, CREATETAB, BINDADD, IMPLICIT_SCHEMA y CREATE_NOT_FENCED de forma implícita. Estos privilegios permanecerán con el usuario incluso si se revoca la autoridad DBADM.

**PUBLIC es un grupo especial DB2 que incluye a todos los usuarios de una base de datos particular. A diferencia de otros grupos que he mostrado hasta acá, PUBLIC no necesita ser definido a nivel de sistema operativo. Existen algunos privilegios concedidos predeterminadamente a PUBLIC. Por ejemplo, este grupo recibe privilegio CONNECT en la base de datos y privilegio SELECT en las tablas de catálogo automáticamente. Los comandos GRANT y REVOKE pueden emitirse contra el grupo PUBLI, como:

db2 grant select on table sysibm.systables to public
db2 revoke select on table sysibm.systables from public

Privilegios Indirectos

Los privilegios se pueden obtener indirectamente cuando los paquetes sean ejecutados por el gestor de base de datos. Un paquete contiene uno o más enunciados SQL que han sido convertidos en un formato que DB2 usa internamente para ejecutarlos. En otras palabras, un paquete contiene múltiples enunciados SQL en un formato ejecutable. Si todos los paquetes son estáticos, un usuario solo necesitaría privilegio EXECUTE sobre el paquete para ejecutar exitosamente los enunciados del paquete.

Por ejemplo, suponga que db2package1 ejecuta los siguientes enunciados SQL estáticos:

db2 select * from org
db2 insert into test values (1, 2, 3)

En este caso, un usuario con privilegio EXECUTE sobre db2package1 indirectamente tendría concedido el privilegio SELECT en la tabla org y privilegio INSERT sobre la tabla test.

Control de acceso basado en etiquetas

En DB2 9 es nuevo el concepto de control de acceso basado en etiquetas (LBAC). Lo que el LBAC proporciona al DBA es la capacidad para restringir privilegios de lectura / escritura sobre el nivel de fila o columna de una tabla.

Previamente, la única forma de introducir estas restricciones era crear una vista, autorizar el uso de la vista para el usuario en cuestión y remover el acceso a la tabla base.

Este tutorial solo demostrará un escenario de ejemplo de seguridad LBAC. Para una explicación más detallada del LBAC, consulte DB2 Label-Based Access Control, a practical guide, Part 1: Understand the basics of LBAC in DB2 en developerWorks.

LBAC es configurado por el administrador de seguridad mediante la creación de Políticas de Seguridad. Cada tabla puede ser suscrita a una sola política de seguridad, pero el sistema puede tener tantas políticas de seguridad como usted quiera. Son necesarios varios pasos para configurar un LBAC. Lo primero que debe hacer es determinar el tipo de control de acceso que necesita para sus datos.

Supongamos lo siguiente. En su organización existen tres conjuntos de personas:

Tabla 6. Organización de ejemplo

NombreRol organizacional
JaneEjecutiva de recursos humanos
JoeGestor de los departamentos D11 y E21
FrankLíder de equipo - Departamento A00

Ahora, en la base de datos de la organización existe una tabla que define la información de los empleados. Esta se basará en la tabla EMP de la base de datos SAMPLE. Esta contiene datos sobre los empleados y los departamentos a los que pertenecen. Su definición de existencia es la siguiente:

				db2 => describe select * from emp

SQLDA Information

 sqldaid : SQLDA     sqldabc: 896  sqln: 20  sqld: 14

 Column Information

 sqltype               sqllen  sqlname.data                    sqlname.length
 --------------------  ------  ------------------------------  --------------
 452   CHARACTER            6  EMPNO                                        5
 448   VARCHAR             12  FIRSTNME                                     8
 453   CHARACTER            1  MIDINIT                                      7
 448   VARCHAR             15  LASTNAME                                     8
 453   CHARACTER            3  WORKDEPT                                     8
 453   CHARACTER            4  PHONENO                                      7
 385   DATE                10  HIREDATE                                     8
 453   CHARACTER            8  JOB                                          3
 500   SMALLINT             2  EDLEVEL                                      7
 453   CHARACTER            1  SEX                                          3
 385   DATE                10  BIRTHDATE                                    9
 485   DECIMAL           9, 2  SALARY                                       6
 485   DECIMAL           9, 2  BONUS                                        5
 485   DECIMAL           9, 2  COMM                                         4

La organización tiene reglas en su lugar que son auditadas regularmente. Parte de esta auditoría indica que los empleados no deben tener acceso a datos que sean considerados confidenciales. Las reglas estipulan que los ejecutivos tienen acceso completo de lectura / escritura a los registros de todos los empleados, los gerentes tienen acceso de lectura / escritura a cualquier persona de su departamento, y los líderes de equipo tienen acceso de lectura a cualquier persona del departamento que dirigen.

Para configurar la seguridad LBAC para activar estas reglas:

  1. Defina las políticas y etiquetas de seguridad y asigne etiquetas de seguridad a los usuarios.
  2. Modifique la tabla EMP, incluyendo la columna de etiqueta de seguridad, y anéxele la política de seguridad.

Definiendo las políticas y etiquetas de seguridad

Para definir las políticas y etiquetas de seguridad se requiere la autoridad SECADM.

Paso 1a. Cree el componente de etiqueta de seguridad

Lo primero que usted necesita hacer es determinar el mejor tipo de componente de seguridad a definir para esta política. En este caso en particular, lo que mejor se ajusta es una política tipo "TREE". Una política tipo árbol significa que usted puede definir un conjunto de etiquetas de forma que los hijos tengan un subconjunto de los derechos que tienen sus padres. en este ejemplo, cree un componente de seguridad llamado "J_DEPT".

			CREATE SECURITY LABEL COMPONENT J_DEPT
        TREE ('HR_EXECUTIVE' ROOT,
              'MAN_D11_E21' UNDER 'HR_EXECUTIVE'
              'A00' UNDER 'HR_EXECUTIVE',
              'B01' UNDER 'HR_EXECUTIVE',
              'C01' UNDER 'HR_EXECUTIVE',
              'D11' UNDER 'MAN_D11_E21',
              'D21' UNDER 'HR_EXECUTIVE',
              'E01' UNDER 'HR_EXECUTIVE',
              'E11' UNDER 'HR_EXECUTIVE',
              'E21' UNDER 'MAN_D11_E21'
        )

El diseño de arriba indica que la raíz es HR_EXECUTIVE, y todos los departamentos son hijos bajo ese ejecutivo.

Paso 1b. Defina la política de seguridad

El siguiente paso requerido para usar seguridad LBAC en el ejemplo de arriba es definir la política asociada con el componente de seguridad de arriba. Una política de seguridad puede usar más de un componente.

      	CREATE SECURITY POLICY J_DEPT_POLICY
             COMPONENTS J_DEPT
             WITH DB2LBACRULES
             RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL

Paso 1c. Cree las etiquetas de seguridad

El tercer paso en la configuración de la política de seguridad es crear las etiquetas de seguridad. Es aquí donde usted especificará los diferentes roles que tiene cada usuario. En este caso, como el ejemplo es bastante simple, solo habrá tres etiquetas, Executive, Manager y Team Lead.

      CREATE SECURITY LABEL J_DEPT_POLICY.EXECUTIVE
             COMPONENT J_DEPT 'HR_EXECUTIVE'
             
      CREATE SECURITY LABEL J_DEPT_POLICY.MANAGE_D11_E21
             COMPONENT J_DEPT 'MAN_D11_E21'
             
      CREATE SECURITY LABEL J_DEPT_POLICY.A00
             COMPONENT J_DEPT 'A00'
             
      CREATE SECURITY LABEL J_DEPT_POLICY.B01
             COMPONENT J_DEPT 'B01'
             
      CREATE SECURITY LABEL J_DEPT_POLICY.C01
             COMPONENT J_DEPT 'C01'

      CREATE SECURITY LABEL J_DEPT_POLICY.D11
             COMPONENT J_DEPT 'D11'

      CREATE SECURITY LABEL J_DEPT_POLICY.D21
             COMPONENT J_DEPT 'D21'

      CREATE SECURITY LABEL J_DEPT_POLICY.E01
             COMPONENT J_DEPT 'E01'

      CREATE SECURITY LABEL J_DEPT_POLICY.E11
             COMPONENT J_DEPT 'E11'

      CREATE SECURITY LABEL J_DEPT_POLICY.E21
             COMPONENT J_DEPT 'E21'

En el siguiente paso usted definirá los permisos efectivos asociados con estas etiquetas.

Paso 1d. Derechos concedidos con base en etiquetas

Los siguientes pasos describen los procedimientos para conceder los derechos a los datos de la tabla. Los derechos son ALL ACCESS, WRITE ACCESS, o READ ACCESS. Si a un usuario no se le concede ninguno de estos derechos, entonces ese usuario no tendrá la capacidad de acceder a ningún dato de la tabla. Recuerde que los ejecutivos tienen acceso completo, los gerentes tienen acceso a sus departamentos, y los líderes de equipo tienen acceso de lectura a los miembros del departamento que dirigen.

db2 grant security label J_DEPT_POLICY.A00 to user Frank for read access
db2 grant security label J_DEPT_POLICY.MANAGE_D11_E21 to user Joe for all access
db2 grant security label J_DEPT_POLICY.EXECUTIVE to user Jane for all access

Configurar las anteriores etiquetas transferirá los derechos en forma de cascada con base en las tres definiciones del paso 1a. Como el usuario Joe está etiquetado como MANAGE_D11_E21, y se le han asignado todos los derechos, él podrá leer y escribir filas que tengan la etiqueta de seguridad J_DEPT_POLICY.D11 o J_DEPT_POLICY.E21 (dado que son hijos).

Paso 2: Modifique la tabla EMP

Cuando modifica la tabla EMP, debe crear una columna adicional para almacenar la etiqueta de seguridad. Esta es del tipo "DB2SECURITYLABEL". Usted va a modificar la tabla EMP existente en la base de datos SAMPLE. Para hacerlo, usted necesita hacerlo mediante un usuario al que se le haya concedido privilegio de nivel de raíz en la política, así que en este caso será el usuario Jane. Primero usted debe descartar la tabla MQT ADEFUSR de la base de datos de muestra.

CONNECT TO SAMPLE

   Database Connection Information

 Database server        = DB2/NT 9.1.0
 SQL authorization ID   = GMILNE
 Local database alias   = SAMPLE  

DROP TABLE ADEFUSR

CONNECT RESET

CONNECT TO SAMPLE USER Jane USING password

ALTER TABLE EMP
		ADD COLUMN DEPT_TAG DB2SECURITYLABEL
		ADD SECURITY POLICY J_DEPT_POLICY

Si usted selecciona de la tabla EMP, verá definida la columna adicional. Como usted realizó cambios con un usuario definido en el nivel EXECUTIVE, todas las etiquetas de seguridad habrán sido añadidas como EXECUTIVE. Para hacer esto usted necesita actualizar la tabla.

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE    HAAS            A00        152750.00 HR_EXECUTIVE
000020 MICHAEL      THOMPSON        B01         94250.00 HR_EXECUTIVE
000030 SALLY        KWAN            C01         98250.00 HR_EXECUTIVE
000050 JOHN         GEYER           E01         80175.00 HR_EXECUTIVE
000060 IRVING       STERN           D11         72250.00 HR_EXECUTIVE
000070 EVA          PULASKI         D21         96170.00 HR_EXECUTIVE
000090 EILEEN       HENDERSON       E11         89750.00 HR_EXECUTIVE
000100 THEODORE     SPENSER         E21         86150.00 HR_EXECUTIVE
000110 VINCENZO     LUCCHESSI       A00         66500.00 HR_EXECUTIVE
000120 SEAN         O'CONNELL       A00         49250.00 HR_EXECUTIVE
000130 DELORES      QUINTANA        C01         73800.00 HR_EXECUTIVE
000140 HEATHER      NICHOLLS        C01         68420.00 HR_EXECUTIVE
000150 BRUCE        ADAMSON         D11         55280.00 HR_EXECUTIVE
000160 ELIZABETH    PIANKA          D11         62250.00 HR_EXECUTIVE
000170 MASATOSHI    YOSHIMURA       D11         44680.00 HR_EXECUTIVE
000180 MARILYN      SCOUTTEN        D11         51340.00 HR_EXECUTIVE
000190 JAMES        WALKER          D11         50450.00 HR_EXECUTIVE
000200 DAVID        BROWN           D11         57740.00 HR_EXECUTIVE
000210 WILLIAM      JONES           D11         68270.00 HR_EXECUTIVE
000220 JENNIFER     LUTZ            D11         49840.00 HR_EXECUTIVE
000230 JAMES        JEFFERSON       D21         42180.00 HR_EXECUTIVE
000240 SALVATORE    MARINO          D21         48760.00 HR_EXECUTIVE
000250 DANIEL       SMITH           D21         49180.00 HR_EXECUTIVE
000260 SYBIL        JOHNSON         D21         47250.00 HR_EXECUTIVE
000270 MARIA        PEREZ           D21         37380.00 HR_EXECUTIVE
000280 ETHEL        SCHNEIDER       E11         36250.00 HR_EXECUTIVE
000290 JOHN         PARKER          E11         35340.00 HR_EXECUTIVE
000300 PHILIP       SMITH           E11         37750.00 HR_EXECUTIVE
000310 MAUDE        SETRIGHT        E11         35900.00 HR_EXECUTIVE
000320 RAMLAL       MEHTA           E21         39950.00 HR_EXECUTIVE
000330 WING         LEE             E21         45370.00 HR_EXECUTIVE
000340 JASON        GOUNOT          E21         43840.00 HR_EXECUTIVE
200010 DIAN         HEMMINGER       A00         46500.00 HR_EXECUTIVE
200120 GREG         ORLANDO         A00         39250.00 HR_EXECUTIVE
200140 KIM          NATZ            C01         68420.00 HR_EXECUTIVE
200170 KIYOSHI      YAMAMOTO        D11         64680.00 HR_EXECUTIVE
200220 REBA         JOHN            D11         69840.00 HR_EXECUTIVE
200240 ROBERT       MONTEVERDE      D21         37760.00 HR_EXECUTIVE
200280 EILEEN       SCHWARTZ        E11         46250.00 HR_EXECUTIVE
200310 MICHELLE     SPRINGER        E11         35900.00 HR_EXECUTIVE
200330 HELENA       WONG            E21         35370.00 HR_EXECUTIVE
200340 ROY          ALONZO          E21         31840.00 HR_EXECUTIVE

  42 record(s) selected.

El listado es seguido por lo siguiente:

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','A00')) where WORKDEPT='A00'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','B01')) where WORKDEPT='B01'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','C01')) where WORKDEPT='C01'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','D11')) where WORKDEPT='D11'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','D21')) where WORKDEPT='D21'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E01')) where WORKDEPT='E01'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E11')) where WORKDEPT='E11'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E21')) where WORKDEPT='E21'

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE    HAAS            A00        152750.00 A00
000020 MICHAEL      THOMPSON        B01         94250.00 B01
000030 SALLY        KWAN            C01         98250.00 C01
000050 JOHN         GEYER           E01         80175.00 E01
000060 IRVING       STERN           D11         72250.00 D11
000070 EVA          PULASKI         D21         96170.00 D21
000090 EILEEN       HENDERSON       E11         89750.00 E11
000100 THEODORE     SPENSER         E21         86150.00 E21
000110 VINCENZO     LUCCHESSI       A00         66500.00 A00
000120 SEAN         O'CONNELL       A00         49250.00 A00
000130 DELORES      QUINTANA        C01         73800.00 C01
000140 HEATHER      NICHOLLS        C01         68420.00 C01
000150 BRUCE        ADAMSON         D11         55280.00 D11
000160 ELIZABETH    PIANKA          D11         62250.00 D11
000170 MASATOSHI    YOSHIMURA       D11         44680.00 D11
000180 MARILYN      SCOUTTEN        D11         51340.00 D11
000190 JAMES        WALKER          D11         50450.00 D11
000200 DAVID        BROWN           D11         57740.00 D11
000210 WILLIAM      JONES           D11         68270.00 D11
000220 JENNIFER     LUTZ            D11         49840.00 D11
000230 JAMES        JEFFERSON       D21         42180.00 D21
000240 SALVATORE    MARINO          D21         48760.00 D21
000250 DANIEL       SMITH           D21         49180.00 D21
000260 SYBIL        JOHNSON         D21         47250.00 D21
000270 MARIA        PEREZ           D21         37380.00 D21
000280 ETHEL        SCHNEIDER       E11         36250.00 E11
000290 JOHN         PARKER          E11         35340.00 E11
000300 PHILIP       SMITH           E11         37750.00 E11
000310 MAUDE        SETRIGHT        E11         35900.00 E11
000320 RAMLAL       MEHTA           E21         39950.00 E21
000330 WING         LEE             E21         45370.00 E21
000340 JASON        GOUNOT          E21         43840.00 E21
200010 DIAN         HEMMINGER       A00         46500.00 A00
200120 GREG         ORLANDO         A00         39250.00 A00
200140 KIM          NATZ            C01         68420.00 C01
200170 KIYOSHI      YAMAMOTO        D11         64680.00 D11
200220 REBA         JOHN            D11         69840.00 D11
200240 ROBERT       MONTEVERDE      D21         37760.00 D21
200280 EILEEN       SCHWARTZ        E11         46250.00 E11
200310 MICHELLE     SPRINGER        E11         35900.00 E11
200330 HELENA       WONG            E21         35370.00 E21
200340 ROY          ALONZO          E21         31840.00 E21

  42 record(s) selected.

Después de la actualización, vamos a ver lo que pueden hacer los usuarios individuales. Usted se conectará a la base de datos usando el ID de usuario ejecutivo ID Jane. Comience con el mismo enunciado ejecutado antes:

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE    HAAS            A00        152750.00 A00
000020 MICHAEL      THOMPSON        B01         94250.00 B01
000030 SALLY        KWAN            C01         98250.00 C01
000050 JOHN         GEYER           E01         80175.00 E01
000060 IRVING       STERN           D11         72250.00 D11
000070 EVA          PULASKI         D21         96170.00 D21
000090 EILEEN       HENDERSON       E11         89750.00 E11
000100 THEODORE     SPENSER         E21         86150.00 E21
000110 VINCENZO     LUCCHESSI       A00         66500.00 A00
000120 SEAN         O'CONNELL       A00         49250.00 A00
000130 DELORES      QUINTANA        C01         73800.00 C01
000140 HEATHER      NICHOLLS        C01         68420.00 C01
000150 BRUCE        ADAMSON         D11         55280.00 D11
000160 ELIZABETH    PIANKA          D11         62250.00 D11
000170 MASATOSHI    YOSHIMURA       D11         44680.00 D11
000180 MARILYN      SCOUTTEN        D11         51340.00 D11
000190 JAMES        WALKER          D11         50450.00 D11
000200 DAVID        BROWN           D11         57740.00 D11
000210 WILLIAM      JONES           D11         68270.00 D11
000220 JENNIFER     LUTZ            D11         49840.00 D11
000230 JAMES        JEFFERSON       D21         42180.00 D21
000240 SALVATORE    MARINO          D21         48760.00 D21
000250 DANIEL       SMITH           D21         49180.00 D21
000260 SYBIL        JOHNSON         D21         47250.00 D21
000270 MARIA        PEREZ           D21         37380.00 D21
000280 ETHEL        SCHNEIDER       E11         36250.00 E11
000290 JOHN         PARKER          E11         35340.00 E11
000300 PHILIP       SMITH           E11         37750.00 E11
000310 MAUDE        SETRIGHT        E11         35900.00 E11
000320 RAMLAL       MEHTA           E21         39950.00 E21
000330 WING         LEE             E21         45370.00 E21
000340 JASON        GOUNOT          E21         43840.00 E21
200010 DIAN         HEMMINGER       A00         46500.00 A00
200120 GREG         ORLANDO         A00         39250.00 A00
200140 KIM          NATZ            C01         68420.00 C01
200170 KIYOSHI      YAMAMOTO        D11         64680.00 D11
200220 REBA         JOHN            D11         69840.00 D11
200240 ROBERT       MONTEVERDE      D21         37760.00 D21
200280 EILEEN       SCHWARTZ        E11         46250.00 E11
200310 MICHELLE     SPRINGER        E11         35900.00 E11
200330 HELENA       WONG            E21         35370.00 E21
200340 ROY          ALONZO          E21         31840.00 E21

  42 record(s) selected.

Y el comando de actualización:

db2 => update gmilne.emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E01')) 
where WORKDEPT='E01' DB20000I  The SQL command completed successfully.

Como puede ver, Jane tiene acceso completo a todos los datos de la tabla. Ahora observemos lo que puede ver Joe. Primero, observemos nuevamente el comando select.

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000060 IRVING       STERN           D11         72250.00 D11
000100 THEODORE     SPENSER         E21         86150.00 E21
000150 BRUCE        ADAMSON         D11         55280.00 D11
000160 ELIZABETH    PIANKA          D11         62250.00 D11
000170 MASATOSHI    YOSHIMURA       D11         44680.00 D11
000180 MARILYN      SCOUTTEN        D11         51340.00 D11
000190 JAMES        WALKER          D11         50450.00 D11
000200 DAVID        BROWN           D11         57740.00 D11
000210 WILLIAM      JONES           D11         68270.00 D11
000220 JENNIFER     LUTZ            D11         49840.00 D11
000320 RAMLAL       MEHTA           E21         39950.00 E21
000330 WING         LEE             E21         45370.00 E21
000340 JASON        GOUNOT          E21         43840.00 E21
200170 KIYOSHI      YAMAMOTO        D11         64680.00 D11
200220 REBA         JOHN            D11         69840.00 D11
200330 HELENA       WONG            E21         35370.00 E21
200340 ROY          ALONZO          E21         31840.00 E21

  17 record(s) selected.

¿Ve cómo él solo puede ver información de los departamentos D11 y E21? Vamos a ver qué sucede cuando él intenta seleccionar datos que estén en la tabla, pero que él no tenga permitido ver:

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) 
from gmilne.emp where empno='000130'

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------

  0 record(s) selected.

Del select anterior con Jane sabemos que allí hay un empleado con empno 000130, pero Joe no tiene permitido verlo.

Ahora una última prueba, con Frank.

Primero, se ha ejecutado el mismo select sobre otros dos usuarios:

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE    HAAS            A00        152750.00 A00
000110 VINCENZO     LUCCHESSI       A00         66500.00 A00
000120 SEAN         O'CONNELL       A00         49250.00 A00
200010 DIAN         HEMMINGER       A00         46500.00 A00
200120 GREG         ORLANDO         A00         39250.00 A00

  5 record(s) selected.

En este caso usted puede ver que Frank solo puede ver información sobre usuarios del departamento que él dirige. Observemos qué pasa cuando él trate de actualizar:

db2 => update gmilne.emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','A00')) 
where WORKDEPT='A00'DB21034E  The command was processed as an SQL statement 
because it was not a valid Command Line Processor command.  During SQL processing it 
returned:
SQL20402N Authorization ID "FRANK" does not have the LBAC credentials to
perform the "UPDATE" operation on table "EMPLOYEE".  SQLSTATE=42519

Aunque está tratando de actualizar un registro que está en su propio departamento, usted creó su seguridad de acceso de manera que solo le permita acceso de lectura a la tabla. Nuestros requerimientos de negocios han sido satisfechos.


Resumen

Ahora que ha completado este tutorial, usted debe tener conocimientos básicos sobre los siguientes temas:

Elementos de un plan de seguridad DB2: Usted debe entender la estructura de todo el entorno DB2, lo cual incluye cliente, servidores, gateways y hosts. También debe entender la autenticación, autoridades y los privilegios.

Tipos de autenticación DB2: Usted debe saber cómo configurar tipos de autenticación usando el comando db2 update dbm cfg using authentication type en el servidor, y usando el comando db2 catalog database en el gateway y en el cliente.

Autoridades DB2: Usted debe entender los fundamentos de las autoridades SYSADM, SYSCTRL, SYSMAINT, y SYSMON, las cuales se configuran en el archivo DBM CFG. También debe entender los fundamentos de las autoridades DBADM, LOAD y SECADM, las cuales se establecen usando el comando GRANT y se revocan con el comando REVOKE . Adicionalmente, debe saber cuáles comandos tiene permitido ejecutar cada autoridad.

Privilegios DB2: Usted debe entender los diferentes tipos de privilegios y lo que estos permiten que haga un usuario. Algunos ejemplos son CONTROL, INSERT, DELETE, CREATEIN, DROPIN, REFERENCES, y SELECT. También debe conocer cómo se obtiene/revoca un privilegio de forma explícita (comandos GRANT/REVOKE ), implícitamente, o indirectamente (solo para paquetes). Adicionalmente a esto, usted debe tener un entendimiento básico sobre control de acceso basado en etiquetas y sobre cómo definir diferentes tipos de políticas con base en este nuevo concepto de seguridad.

Para acceder a otros tutoriales de esta serie, añada un marcador a la página de la serie, DB2 9 DBA exam 731 prep tutorials.

Recursos

Aprender

Obtener los productos y tecnologías

  • DB2 9 está disponible para descarga gratuita.
  • DB2 Express-C. Descargue una versión gratuita del DB2 Express Edition para la comunidad que ofrece los mismos recursos de datos principales que el DB2 Express Edition y proporciona una base sólida para construir e implementar aplicaciones.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=966814
ArticleTitle=Preparación para el examen 730 Fundamentos DB2 9, Parte 2: Seguridad
publish-date=03312014