Preparación para El Examen 730 Fundamentos DB2 9, Parte 2

18/4/2018 Preparación para el examen 730 Fundamentos DB2 9, Parte 2: Seguridad
Aprenda Desarrolle Conéctese
Aprenda › Information mgmt
Contenido
Introducción
Antes de comenzar
Seguridad DB2
Autenticación DB2
Autoridades DB2
Privilegios DB2
Resumen
Recursos para Descargar
Temas relacionados
Comentarios
Preparación para el examen 730 Fundamentos DB2 9, Parte 2
Seguridad
Graham Milne
Publicado en 31-03-2014
Antes de comenzar
https://www.ibm.com/developerworks/ssa/data/tutorials/db2-cert7302/index.html 1/39
Sobre esta serie
¿Está pensando en obtener la certificación en fundamentos DB2 (Examen 730)? Si es así, ha lle
serie de siete tutoriales de preparación para la certificación DB2 cubre todo lo básico (los tema
antes de leer la primera pregunta del examen). Incluso si usted no está pensando en obtener la
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 autentic
en DB2 9.
Este es el segundo de una serie de siete tutoriales que usted puede usar para prepararse para e
Certificación en Fundamentos DB2 9. El material de esta tutorial principalmente cubre los objet
prueba, titulada "Seguridad". Usted puede ver estos objetivos en: http://www.ibm.com/certify/t
Prerrequisitos
Para comprender los conceptos descritos en este tutorial, usted ya debe contar con conocimien
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® operativ
seguridad nativos). No obstante, los conceptos y la información proporcionada son relevantes p
cualquier plataforma distribuida.
Usted no necesita tener una copia DB2 9 para completar este tutorial. No obstante, aprovechar
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 grup
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
4. Haber creado un segundo ID de usuario en la máquina en la que se instaló en DB2. En este
usaremos el ID de usuario test1. Note que el usuario test1 no es miembro del grupo de Adm
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 pued

comprar productos en Internet, o puede contener datos históricos usados para predecir tenden
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 pla
datos: autenticación, autoridad y privilegios.
La autenticación es el primer recurso de seguridad que usted encontrará cuando intente accede
datos DB2. La autenticación DB2 funciona muy de cerca con los recursos de seguridad del siste
verificar los ID y contraseñas de usuario. DB2 también puede trabajar con protocolos de segurid
autenticar usuarios.
La autoridad involucra determinar las operaciones que los usuarios y/o grupos pueden efectuar
que pueden acceder. La capacidad de un usuario para efectuar operaciones de alto nivel de adm
de instancia, está determinada por las autoridades que se le hayan asignado. Existen cinco nive
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
ayudan a definir los objetos que un usuario puede crear o descartar. Estos también definen los
puede usar para acceder a objetos como tablas, vistas índices y paquetes. En el DB2 9 es nuevo
acceso basado en etiquetas (LBAC), el cual permite un control más granular sobre quién puede
individuales.
Para prepararse para la siguiente sección del tutorial, usted necesita crear bases de datos dent
Asegúrese de que la variable %DB2INSTANCE% todavía esté definida para DB2, y luego cree la bas
el comando db2sampl unidad, usando el nombre de la unidad donde desee crear la muestra. P
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 hos
seguridad de todo el entorno de base de datos. Con frecuencia un entorno de base de datos con
diferentes; usted debe salvaguardar la base de datos y cualquier punto potencial de acceso a d
clientes, servidores, gateways y hosts son particularmente importantes cuando se está tratand
El siguiente diagrama ilustra una configuración básica cliente-servidor-host.
Figura 1. Configuración básica cliente-servidor-host
 Haga clic para ampliar la imagen
El servidor de base de datos es la máquina (o máquinas de un sistema de bases de datos partic

físicamente la base de datos. Los clientes de base de datos DB2 son máquinas que están config
contra la base de datos que está en el servidor. Estos clientes pueden ser locales (residen en la
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 op
(iSeries®) o OS/390® (zSeries®), se llama un host o servidor host. Una gateway es una máquina q
Connect. Mediante el gateway, las máquinas cliente DB2 pueden conectarse a una base de dato
máquina host. A el gateway también se le conoce como el DB2 Connect Server. Los sistemas co
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 v
attach o connect . Los comandos attach se usan para conectar la instancia DB2, mientras que lo
para conectarse a una base de datos dentro de una instancia DB2. Los siguientes ejemplos le m
en que DB2 autenticará al usuario que esté emitiendo estos comandos. Estos ejemplos usan el
predeterminado de tipo SERVER del archivo de configuración de gestor de base de datos. El eje
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
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
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 v
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
contraseña para test1 es cambiada por el sistema operativo, de password a chgpass. como resu
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 autentica
entorno de cliente-servidor, ¿el cliente o la máquina de servidor verificarán el ID y la contraseña
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 dependiend

intentando conectarse con la base de datos o efectuar acoples de instancia y operaciones de ni
predeterminada, la instancia se configura para que use un tipo de autenticación para todas las
instancia y de nivel de conexión. Esto es especificado por el parámetro AUTHENTICATION del D
Configuration. Introducido en la V9.1, es el parámetro SRVCON_AUTH del Database Manager C
trata específicamente con conexiones con bases de datos. Así, por ejemplo, si usted tiene el sig
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
autenticación KERBEROS. Si KERBEROS no fue inicializado adecuadamente para el servidor pe
ID/contraseña de usuario válidos, entonces al usuario se le permitirá acoplarse a la instancia, p
conectarse a la base de datos.
La siguiente tabla resume los tipos de autenticación DB2 disponibles. En un entorno cliente-gat
autenticación se establecen en el cliente y el gateway, no en la máquina host. A lo largo de esta
detalle cómo configurar estas opciones. Consulte Clientes, servidores, gateways, y hosts como
Tabla 1. Tipos de autenticación DB2
Tipo Descripció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

cliente antes de ser enviadas al servidor.
CLIENT La autenticación se lleva a cabo en la máquina cliente (vea Man

para excepciones).
*KERBEROS La autenticación es llevada a cabo por el software de seguridad
*KRB_SERVER_ENCRYPT La autenticación es llevada a cabo por el software de seguridad

de cliente es KERBEROS. En caso contrario, se utiliza SERVER_
DATA_ENCRYPT La autenticación se lleva a cabo en el servidor. El servidor acept

cifradas del usuario y descifra los datos. Esto funciona de la mis
SERVER_ENCRYPT, excepto que los datos también son cifrados
Tipo Descripción
DATA_ENCRYPT_CMP La autenticación es la misma que para DATA_ENCRYPT, excepto

que clientes antiguos que el esquema DATA_ENCRYPT no perm
autenticación SERVER_ENCRYPT. En este caso los datos no ser
se está conectando soporta DATA_ENCRYPT, es forzado a cifrar
a autenticación SERVER_ENCRYPT. Esta autenticación solo es v
configuración de gestor de base de datos del servidor y no es vá
comando CATALOG DATABASE en una instancia de cliente o de
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.

soporte alguno de los plug-in GSS-API del servidor, se utiliza au
SERVER_ENCRYPT.
*Estas configuraciones solo son válidas para sistemas operativos Windows 2000®, AIX®, Solaris
Configurando la autenticación en el servidor
La autenticación se establece en el servidor de base de datos dentro del archivo Database Man
usando el parámetro AUTHENTICATION. Recuerdo, el archivo DBM CFG es un archivo de config
Así, el parámetro AUTHENTICATION afecta a todas las bases de datos dentro de la instancia. Lo
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

Database Manager Configuration, como TRUST_ALLCLNTS, SRV_PLUGIN_MODE y SRVCON_PW
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. P

una base de datos de muestra llamada myhostdb.
Para establecer el tipo de autenticación de gateway en SERVER, usted emite el siguiente coman
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 autentic
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
datos en una máquina de servidor (DB2 UDB LUW plataforma distribuida), y la otra para que se
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

base de datos para la base de datos que se está conectando debe coincidir con el servidor d
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á

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 fo
• Cliente conectándose a una base de datos host: Supongamos que el tipo de autenticación
Si no se especifica un tipo de autenticación, se asume autenticación SERVER_ENCRYPT cua
base de datos mediante DB2 Connect. La autenticación se llevará a cabo en el servidor de b
comando emitido desde el cliente causará que el cliente envíe IDs de usuario y contraseñas
db2 catalog database myhostdb at node nd1 authentication SERVER
Ahora supongamos que la autenticación se establece como SERVER_ENCRYPT en el gatewa
cabo nuevamente en el servidor de base de datos host. El ID de usuario y contraseña son ci

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 e

autentique el ID y la contraseña del usuario. Sin embargo, algunas máquinas de cliente no tiene
recursos de seguridad nativos. Tales clientes no confiables incluyen clientes DB2 ejecutándose
ME®. DB2 V9.1 no soporta Windows 98 ni Windows ME, pero soporta clientes de nivel inferior p
tratar con clientes no confiables V8.
Hay dos parámetros adicionales en el archivo DBM CFG para determinar dónde debe darse la a
de autenticación de servidor o de gateway está en CLIENT y hay clientes no confiables intentan
datos o acoplarse a la instancia DB2. Estos son los parámetros TRUST_ALLCLNTS y TRUST_CLN
Cuando el tipo de autenticación del servidor o el gateway es CLIENT, hay otros dos factores que
los parámetros TRUST_ALLCLNTS y TRUST_CLNTAUTH. El primero es si se suministraron un ID
explícitamente, y el segundo es el tipo de cliente que se está conectando. Los tres clientes dB2
• 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 t
nativos como Windows NT®, Windows 2000®, Windows 2003®, Windows XP, y todas las form
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
attach hacia un servidor cuyo tipo de autenticación esté configurado en CLIENT.
Tabla 2. Autenticación tras comando connect o attach
¿Se suministró TRUST_ALLCLNTS TRUST_CLNTAUTH Cl

ID/Contraseña de co
usuario?
Nosuministró
+ ¿Se Yes
TRUST_ALLCLNTS TRUST_CLNTAUTH
CLIENT Cl
CL
ID/Contraseña de co
usuario?
+ No Yes SERVER CL
+ No No CLIENT SE
+ No No SERVER SE
+ No DRDAONLY CLIENT SE
+ No DRDAONLY SERVER SE
+ Yes Yes CLIENT CL
+ Yes Yes SERVER SE
+ Yes No CLIENT SE
+ Yes No SERVER SE
+ Yes DRDAONLY CLIENT SE
+ Yes DRDAONLY SERVER SE
DRDAONLY se refiere a clientes host únicamente, sin importar el hecho de que los clientes DB2
conectan usando DRDA.
Los siguientes ejemplos ilustran la configuración de tipos y parámetros de autenticación en ser
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
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 mejo
Usando llamados GSS-API estándar un usuario puede escribir un plug-in de seguridad y pasar e
ID de usuario a un programa de seguridad externo. Un ejemplo de esto es la propia autenticació
usted instala DB2 ESE, o el cliente de desarrollo de aplicaciones en una máquina, parte de esa
aplicación de muestra en su instancia de directorio. Si usted observa en el directorio samples\s
tres ejemplos sobre cómo codificar plug-ins de seguridad. Esta sección describirá el uso de plu
seguridad DB2, pero no cubre cómo codificar o compilar los plug-in en sí. Para una descripción
esto, consulte DB2 UDB Security Part 2: Understand the DB2 Universal Database Security plug-
Autenticación Kerberos
La autenticación Kerberos proporciona a DB2 una forma para autenticar usuarios sin tener que
de usuario sobre la red. El protocolo de seguridad Kerberos lleva a cabo autenticación como un
externo, usando criptografía convencional para crear una clave secreta compartida. Esta clave s
del usuario y se utiliza para verificar la identidad de los usuarios durante todas las veces que se
locales. El uso del protocolo de seguridad Kerberos permite el uso de inicio único de sesión par
de datos DB2.
Primero, vamos a revisar la configuración DB2 para usar autenticación Kerberos. Como se menc
Kerberos es implementada en DB2 usando la arquitectura de plug-in. El código fuente para el p
Kerberos se suministra en el directorio samples/security/plugins , llamado IBMkrb5.c. Antes
Kerberos funcione para DB2, Kerberos debe activarse y ser soportado tanto en el cliente como
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 a
Para permitir que DB2 use autenticación KERBEROS usted primero debe decirle al cliente dónd
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 modifica
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 s
opción salta el primer paso de autenticación Kerberos en donde el cliente debe descubrir el ser
la que se está conectando. El parámetro AUTHENTICATION puede ser especificado cuando se e
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_

parámetro puede configurarse con una lista de los diferentes plug-in GSS-API soportados, pero
plug-in Kerberos. Si en la lista no hay plug-in Kerberos, se utilizará automáticamente el plug-in
usted pretende permitir que toda la autenticación (acoples de instancia así como conexiones de
Kerberos, entonces ejecute lo siguiente:
DB2 UPDATE DBM CFG USING AUTHENTICATION KERBEROS
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
acoples de instancia entrantes), entonces ejecute lo siguiente:
DB2 UPDATE DBM CFG USING SVRCON_AUTH KERBEROS
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 plu
la instancia.
Otras configuraciones de autenticación
Si usted observa en el DBM CFG para una instancia V9.1, verá varias configuraciones que puede
DB2 autenticará los ID de usuario. Como se mencionó arriba, existen configuraciones para ID d
(CLIENT, SERVER, SERVER_ENCRYPT, DATA_ENCRYPT, DATA_ENCRYPT_CMP), así como plug-in
programas externos (KERBEROS, KRB_SERVER_ENCRYPT, GSSPLUGIN, GSS_SERVER_ENCRYP
específicamente algunas de las otras variables de configuración que pueden tener un impacto e
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_PLUGIN Este parámetro es especificado en el DBM CFG del lado del clien
del plug-in de cliente usado para autenticación de cliente y loca
GROUP_PLUGIN El predeterminado de este valor es en blanco (NULL). Configurar

definido por el usuario invocará ese plug-in para toda la enumer
depender de la búsqueda de grupo del sistema operativo. Esto e
secciones de autoridad que se tratan más adelante.
LOCAL_GSSPLUGIN Este parámetro especifica el nombre de la biblioteca de plug-in

autorización local de nivel de instancia cuando el valor del parám
configuración del gestor de base de datos sea GSSPLUGIN o GSS
SRV_PLUGIN_MODE (YES/NO) El valor predeterminado para este parámetro es NO. C

plug-in GSS-API usados se inician en modo FENCED, de forma s
funcionan los procedimientos almacenados FENCED. Un plug-in
hacer que la instancia DB2 también falle. Mientras se desarrolla
que los ejecute en modo fenced para que los problemas lógicos
esos plug-in no hagan fallar la instancia. En cuanto se determina
debe ejecutar unfenced por razones de desempeño.
SRVCON_GSSPLUGIN_LIST Se utiliza una lista de plug-ins que el gestor de la base de datos

la autenticación, con KERBEROS o con KRB_SERVER_ENCRYPT,
GSS_SERVER_ENCRYPT. Cada plug-in de la lista deberá estar se
espacios intermedios. Los plug-in se listan en orden de preferen
lista se usa primero para intentar autenticar el ID / contraseña d
cuando todos los plug-in enviados hayan retornado un error DB2
autenticación al usuario.
SRVCON_PW_PLUGIN Este parámetro permite al usuario cambiar la autenticación pred

verificad ID y contraseñas de usuario cuando se especifican aute
o SERVER_ENCRYPT. De forma predeterminada, su valor es NUL
DB2 predeterminados.
CATALOG_NOAUTH (YES/NO) Predeterminado en NO. Cambiar este parámetro a YES

no están verificados para ser miembros de los grupos SYSADM,
cambiar los catálogos Database, Node, Admin y DCS de la máqu
escenarios de cliente donde el usuario que inició sesión en la má
no confiable (definido arriba) o ha iniciado sesión con un ID de u
conectarse a la base de datos o acoplarse a la instancia, pero de
máquina cliente.
FED_NOAUTH Cuando fed_noauth esté en yes, la autenticación se configura en

federated si está en yes, entonces se salta la autenticación en la
autenticación sucederá en la fuente de datos. Tenga cuidado cu
La autenticación no se efectúa ni en el cliente ni en DB2. Cualqu
nombre de autenticación SYSADM puede asumir autoridad SYSA
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 m
de gestor de base de datos (nivel de instancia). De las cinco autoridades disponibles en DB2, SY
SYSMON son autoridades de nivel de instancia. Eso significa que su alcance incluye comandos d
comandos contra todas las bases de datos dentro de la instancia. Estas autoridades solo puede
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 p
hacer de forma explícita usando el comando GRANT .
Las siguientes secciones describen cómo se asigna cada autoridad y cuáles comandos pueden
autoridad. Note que cualquier referencia a membresía de grupo implica que los nombres de usu
definidos a nivel de sistema operativo.
Los usuarios pueden determinar cuáles autoridades y privilegios de nivel de base de datos tiene
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 Admin

usuarios con autoridad SYSADM para una instancia DB2 pueden ejecutar cualquier comando DB
cualquier base de datos dentro de la instancia y cualquier objeto dentro de esas bases de datos
capacidad para acceder a datos dentro de la base de datos y a conceder o revocar privilegios y
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_GR

instancia, este parámetro se configura a Administrador en Windows (aunque aparece en blanco
get dbm cfg ). En UNIX, se establece para que sea el grupo principal del usuario que creó la ins
Como los usuarios SYSADM son los únicos usuarios a los que se les permite actualizar el archiv
únicos que tienen permitido conceder cualquiera de las autoridad SYS* a otros grupos. El siguie
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. Ten
usted actualmente no está en sesión activa como miembro dedb2grp1, ¡tal vez no tenga autorid
Es posible que tenga que cerrar sesión y volver a iniciarla con un ID del grupo correcto, o añadir
Obteniendo autoridad SYSCTRL
Los usuarios con autoridad SYSCTRL pueden ejecutar todos los comandos administrativos y de
instancia. No obstante, a diferencia de los usuarios SYSADM, estos no pueden acceder a ningún
menos que se les concedan los privilegios para hacerlo. Algunos ejemplos de comandos que pu
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 coma
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 d
con la autoridad SYSCTRL. Los usuarios SYSMAINT solo pueden ejecutar tareas de mantenimie
• 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 d
acceder a ningún dato de las bases de datos, a menos que se les concedan los privilegios para h
Si usted tiene autoridad SYSADM, puede asignar autoridad SYSMAINT a un grupo usando el sig
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ó

datos, de una instancia de gestor de base de datos o de sus bases de datos. La autoridad SYSM
especificado por el parámetro de configuración sysmon_group . Si se especifica un grupo, la me
controlada por fuera del gestor de base de datos mediante el recurso de seguridad usado por s
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() almacenamien
• 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
previamente SYSPROC.SNAP_WRITE_FILE. SYSPROC.SNAP_WRITE_FILE realiza una captura instan
un archivo. Si se llama a cualquier función de tabla de captura instantánea con parámetros de e
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 auto
Un usuario con autoridad SYSADM puede asignar SYSMON a un grupo usando el siguiente coma
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 nive
usuarios DBADM tiene control total sobre una base de datos (casi). Los usuarios DBADM no pue
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
contenidos. Como la autoridad DBADM es una autoridad de nivel de base de datos, puede asign
grupos. Los siguientes comandos ilustran diferentes formas en las que usted puede conceder a
• db2 create database test
Este comando da autoridad DBADM implícita sobre la base de datos llamada test al usuario
• 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 DBA
de datos de muestra. Note que el usuario que lo emite debe estar conectado a la base de da
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 l
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
a grupos. Como su nombre lo indica, la autoridad LOAD autoriza a los usuarios a emitir el coman
comando LOAD se utiliza normalmente como una alternativa más rápida que los comandos inse
llenando una tabla con grandes cantidades de datos. Dependiendo del tipo de LOAD que desee
autoridad LOAD no es suficiente. También pueden llegar a requerirse privilegios específicos sob
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 sobr
• 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
Solo los usuarios con autoridad SYSADM o DBADM tienen permitido conceder o revocar autorid
grupos. Los siguientes ejemplos ilustran cómo la autoridad LOAD puede permitir al usuario LOA
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 REST
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 pued
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
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
explícitamente a ese usuario SYSADM. Esto es muy importante porque estas capacidades de se
y solo se deben conceder a usuarios que estén definidos como administradores de seguridad. V
acceso basado en etiquetas" para más información sobre este nuevo recurso de seguridad en D
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

categorías principales: privilegios de nivel de base de datos, los cuales abarcan todos los objeto
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 BIN
• CONNECT: Los usuarios pueden conectarse a la base de datos.
• CREATE_NOT_FENCED: Los usuarios pueden crear funciones unfenced definidas por usuari
• IMPLICIT_SCHEMA: Los usuarios pueden crear esquemas de forma implícita dentro de la ba

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
temporal.
• CREATE_EXTERNAL_ROUTINE: Los usuarios pueden crear un procedimiento para que sea u

otros usuarios de la base de datos.
Losobjetos de base de datos incluyen tablas, vistas, índices, esquemas y paquetes. afortunadam
de nivel de objeto se explican por sí mismos. La siguiente tabla resume estos privilegios.
Tabla 4. Resumen de privilegios

Nombre del Objetos relevantes Descripción

privilegio
CONTROL Tabla, Vista, Índices, Paquetes, Proporciona autoridad completa sob

Alias, Tipo Distintivo, Función este privilegio también pueden conc
definida por usuario, Secuencia sobre el objeto para otros usuarios.
DELETE Tabla, Vista Permite a los usuarios eliminar regis
INSERT Tabla, Vista Permite a los usuarios insertar regist

comandos INSERT e IMPORT.
SELECT Tabla, Vista Proporciona a los usuarios la capacid

objeto usando el enunciado select.
UPDATE Tabla, Vista Permite a los usuarios modificar reg

usando el enunciado update.
ALTER Tabla Permite a los usuarios alterar la defi

enunciado alter.
INDEX Tabla Permite a los usuarios crear índices

enunciado index.
REFERENCES Tabla Proporciona a los usuarios la capacid

restricción de claves foráneas sobre
BIND Paquete Permite a los usuarios volver a vincu
EXECUTE Paquete, Procedimiento, Función, Permite a los usuarios ejecutar paqu

Método
ALTERIN Esquema Permite a los usuarios modificar defi

del esquema.
CREATEIN Esquema Permite a los usuarios crear objetos
Nombre del Objetos relevantes Descripción

privilegio
DROPIN Esquema Permite a los usuarios descartar obj
En las vistas del catálogo de sistema hay información almacenada sobre privilegios de nivel de
vistas son syscat.tabauth, syscat.colauth, syscat.indexauth, syscat.schemaauth, syscat
syscat.packageauth.
Privilegios explícitos
Los privilegios se pueden conceder y revocar de forma explícita a usuarios o grupos, usando los
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 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:
Recuerde, los comandos de la Ventana 1 están siendo emitidos por un usuario con autoridad SY
Ventana 2 están siendo emitidos por tst1, un usuario sin autoridad ni privilegios específicos en
Note que el nombre de esquema asociado con las tablas de su base de datos de muestra será e
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 Ven
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
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 d
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 miem
ejemplo, el siguiente comando pudo haberse usado para revocar todos los privilegios (excepto
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 lo
que se le ha concedido el privilegio directamente.
Privilegios Implícitos
DB2 puede conceder privilegios automáticamente cuando se emiten ciertos comandos, sin nec
enunciado GRANT explícito, como vio previamente. La siguiente tabla resume algunos comando
privilegios que están siendo concedidos implícitamente por el gestor de base de datos. Note qu
revocados implícitamente cuando se descarta el objeto creado. No obstante, estos no son revoc
explícitamente privilegios de nivel superior.
Tabla 5. Comandos resultantes de privilegios que están siendo co

implícitamente por el gestor de base de datos
Comando Privilegio concedido

emitido
CREATE TABLE CONTROL en mytable

mytable
CREATE SCHEMA CREATEIN, ALTERIN, DROPIN en myschema, más la capacidad de conceder

myschema estos a otros
CREATE VIEW CONTROL en myview solo si CONTROL se mantiene en todas la tablas y vista
myview referenciadas en la definición de myview
CREATE SELECT en tablas de catálogo de sistema de mydb , IMPLICIT_SCHEMA en

DATABASE mydb mydb *
*Cuando un usuario crea una base de datos, a ese usuario se le concede autoridad DBADM imp
datos. Con la autoridad DBADM se incluyen los privilegios CONNECT, CREATETAB, BINDADD, IM
CREATE_NOT_FENCED de forma implícita. Estos privilegios permanecerán con el usuario inclus
DBADM.
**PUBLIC es un grupo especial DB2 que incluye a todos los usuarios de una base de datos part
grupos que he mostrado hasta acá, PUBLIC no necesita ser definido a nivel de sistema operativ
concedidos predeterminadamente a PUBLIC. Por ejemplo, este grupo recibe privilegio CONNEC
privilegio SELECT en las tablas de catálogo automáticamente. Los comandos GRANT y REVOKE
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 g
paquete contiene uno o más enunciados SQL que han sido convertidos en un formato que DB2
ejecutarlos. En otras palabras, un paquete contiene múltiples enunciados SQL en un formato ej
son estáticos, un usuario solo necesitaría privilegio EXECUTE sobre el paquete para ejecutar ex
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 co
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 LBA
capacidad para restringir privilegios de lectura / escritura sobre el nivel de fila o columna de un
Previamente, la única forma de introducir estas restricciones era crear una vista, autorizar el us
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
consulte DB2 Label-Based Access Control, a practical guide, Part 1: Understand the basics of LB
developerWorks.
LBAC es configurado por el administrador de seguridad mediante la creación de Políticas de Seg

suscrita a una sola política de seguridad, pero el sistema puede tener tantas políticas de seguri
necesarios varios pasos para configurar un LBAC. Lo primero que debe hacer es determinar el t
necesita para sus datos.
Supongamos lo siguiente. En su organización existen tres conjuntos de personas:
Tabla 6. Organización de ejemplo
Nombre Rol organizacional
Jane Ejecutiva de recursos humanos
Joe Gestor de los departamentos D11 y E21
Frank Lí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 e
la tabla EMP de la base de datos SAMPLE. Esta contiene datos sobre los empleados y los depar
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í
deben tener acceso a datos que sean considerados confidenciales. Las reglas estipulan que los
completo de lectura / escritura a los registros de todos los empleados, los gerentes tienen acce
cualquier persona de su departamento, y los líderes de equipo tienen acceso de lectura a cualq
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ític
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
este caso en particular, lo que mejor se ajusta es una política tipo "TREE". Una política tipo árbo
definir un conjunto de etiquetas de forma que los hijos tengan un subconjunto de los derechos
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 ba
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íti
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

especificará los diferentes roles que tiene cada usuario. En este caso, como el ejemplo es basta
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'


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
ACCESS, WRITE ACCESS, o READ ACCESS. Si a un usuario no se le concede ninguno de estos de
no tendrá la capacidad de acceder a ningún dato de la tabla. Recuerde que los ejecutivos tienen
gerentes tienen acceso a sus departamentos, y los líderes de equipo tienen acceso de lectura a
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 la
Como el usuario Joe está etiquetado como MANAGE_D11_E21, y se le han asignado todos los d
escribir filas que tengan la etiqueta de seguridad J_DEPT_POLICY.D11 o J_DEPT_POLICY.E21 (
Paso 2: Modifique la tabla EMP
Cuando modifica la tabla EMP, debe crear una columna adicional para almacenar la etiqueta de
"DB2SECURITYLABEL". Usted va a modificar la tabla EMP existente en la base de datos SAMPLE
hacerlo mediante un usuario al que se le haya concedido privilegio de nivel de raíz en la política
usuario Jane. Primero usted debe descartar la tabla MQT ADEFUSR de la base de datos de mue
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ó cam
en el nivel EXECUTIVE, todas las etiquetas de seguridad habrán sido añadidas como EXECUTIV
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
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','B01')) where WORKDEPT
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','C01')) where WORKDEPT
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','D11')) where WORKDEPT
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','D21')) where WORKDEPT
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E01')) where WORKDEPT

varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from emp

------ ------------ --------------- -------- ----------- -----------------------
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
Después de la actualización, vamos a ver lo que pueden hacer los usuarios individuales. Usted s
usando el ID de usuario ejecutivo ID Jane. Comience con el mismo enunciado ejecutado antes:


------ ------------ --------------- -------- ----------- -----------------------
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
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
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
200120 GREG ORLANDO A00 39250.00 A00
200140 KIM NATZ C01 68420.00 C01
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
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 l
observemos nuevamente el comando select.


------ ------------ --------------- -------- ----------- -----------------------
000060 IRVING STERN D11 72250.00 D11
000150 BRUCE ADAMSON D11 55280.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
200220 REBA JOHN D11 69840.00 D11
200330 HELENA WONG E21 35370.00 E21
200340 ROY ALONZO E21 31840.00 E21
¿Ve cómo él solo puede ver información de los departamentos D11 y E21? Vamos a ver qué suc
seleccionar datos que estén en la tabla, pero que él no tenga permitido ver:

varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30)
from gmilne.emp where empno='000130'

------ ------------ --------------- -------- ----------- -----------------------
Del select anterior con Jane sabemos que allí hay un empleado con empno 000130, pero Joe n
Ahora una última prueba, con Frank.
Primero, se ha ejecutado el mismo select sobre otros dos usuarios:


------ ------------ --------------- -------- ----------- -----------------------
000120 SEAN O'CONNELL A00 49250.00 A00
200120 GREG ORLANDO A00 39250.00 A00
En este caso usted puede ver que Frank solo puede ver información sobre usuarios del departa
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 processin
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ó
manera que solo le permita acceso de lectura a la tabla. Nuestros requerimientos de negocios h
Resumen
Ahora que ha completado este tutorial, usted debe tener conocimientos básicos sobre los sigui
Elementos de un plan de seguridad DB2: Usted debe entender la estructura de todo el entorno
servidores, gateways y hosts. También debe entender la autenticación, autoridades y los privile
Tipos de autenticación DB2: Usted debe saber cómo configurar tipos de autenticación usando
cfg using authentication type en el servidor, y usando el comando db2 catalog database
Autoridades DB2: Usted debe entender los fundamentos de las autoridades SYSADM, SYSCTRL
cuales se configuran en el archivo DBM CFG. También debe entender los fundamentos de las au
SECADM, las cuales se establecen usando el comando GRANT y se revocan con el comando REVO
saber cuáles comandos tiene permitido ejecutar cada autoridad.
Privilegios DB2: Usted debe entender los diferentes tipos de privilegios y lo que estos permiten
ejemplos son CONTROL, INSERT, DELETE, CREATEIN, DROPIN, REFERENCES, y SELECT. Tambi
obtiene/revoca un privilegio de forma explícita (comandos GRANT/REVOKE ), implícitamente, o in
paquetes). Adicionalmente a esto, usted debe tener un entendimiento básico sobre control de a
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 D
Recursos para Descargar
 PDF de este contenido
Temas relacionados
• DB2 9 está disponible para descarga gratuita.
• DB2 Express-C. Descargue una versión gratuita del DB2 Express Edition para la comunidad
recursos de datos principales que el DB2 Express Edition y proporciona una base sólida par
aplicaciones.
• Examen de certificación sitio. Haga clic en el número del examen para ver más información
731.
• Visión general del DB2 9. Encuentre información sobre el nuevo servidor de datos que inclu
pureXML.
• El DB2 9 Information Center. Aprenda más sobre seguridad DB2.
• DB2 UDB Security Part 2: Understand the DB2 Universal Database Security plug-ins (develo
describe la implementación DB2 de complementos de seguridad externos, y cómo impleme
Comentarios
Inicie Sesión o Regístrese para agregar comentarios.
Reciba notificaciones de los comentarios
developerWorks
Acerca de
Informar abusos
Aviso de términos legales de terceros
Síguenos
Únete
Universidad
Startups (Inglés)
Business Partners (Inglés)
Seleccione un idioma
English
中文
⽇本語
Русский
Português (Brasil)
Español
한글
Descargas
Boletín (Inglés)
Tutoriales & entrenamientos
Contacto Privacidad Condiciones de uso Accesibilidad Comentarios Preferencias de coo

Preparación para El Examen 730 Fundamentos DB2 9, Parte 2 - Seguridad

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Preparación para El Examen 730 Fundamentos DB2 9, Parte 2 - Seguridad

Transféré par

Droits d'auteur :

Formats disponibles

18/4/2018 Preparación para el examen 730 Fundamentos DB2 9, Parte 2: Seguridad

Aprenda Desarrolle Conéctese

Aprenda › Information mgmt

Recursos para Descargar

Sobre esta serie

Acerca de este tutorial

Para completar los pasos de este tutorial usted debe:

Aspectos de la seguridad de base de datos

La seguridad de bases de datos es de extrema importancia actualmente. Su base de datos pued

Un plan de seguridad para base de datos debe deﬁnir:

• Quién tiene permitido el acceso a la instancia y/o base de datos

• Dónde y cómo se veriﬁcará 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

Mecanismos de seguridad DB2

Clientes, servidores, gateways y hosts

El siguiente diagrama ilustra una conﬁguración básica cliente-servidor-host.

Figura 1. Conﬁguración básica cliente-servidor-host

 Haga clic para ampliar la imagen

El servidor de base de datos es la máquina (o máquinas de un sistema de bases de datos partic

Cuándo autentica DB2

• Quién tiene permitido el acceso a la instancia y/o base de datos

• Dónde y cómo se veriﬁcará la contraseña de un usuario

db2 attach to DB2

db2 connect to sample user test1 using password

Tipos de autenticación DB2

DB2 9 tiene la capacidad para especiﬁcar diferentes mecanismos de autenticación dependiend

DB2 GET DBM CFG

Tabla 1. Tipos de autenticación DB2

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

CLIENT La autenticación se lleva a cabo en la máquina cliente (vea Man

*KERBEROS La autenticación es llevada a cabo por el software de seguridad

*KRB_SERVER_ENCRYPT La autenticación es llevada a cabo por el software de seguridad

DATA_ENCRYPT La autenticación se lleva a cabo en el servidor. El servidor acept

DATA_ENCRYPT_CMP La autenticación es la misma que para DATA_ENCRYPT, excepto

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.

Conﬁgurando la autenticación en el servidor

Para ver el parámetro de autenticación en el archivo de conﬁguració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

Ciertos tipos de autenticación como GSSPLUGIN, KERBEROS y CLIENT requieren la conﬁguraci

Conﬁgurando la autenticación en el gateway

En el gateway la autenticación se establece usando el comando de base de datos de catálogo. P

db2 catalog database myhostdb at node nd1 authentication SERVER

Conﬁgurando la autenticación en el cliente

• Cliente conectándose a una base de datos de servidor: La conﬁguración de autenticación

Supongamos que el tipo de autenticación de servidor está en SERVER. Entonces se emitirá

db2 catalog database sample at node nd1 authentication SERVER

Si no se especiﬁca el tipo de autenticación, el cliente intentará usar SERVER_ENCRYPT de fo

Ahora supongamos que la autenticación se establece como SERVER_ENCRYPT en el gatewa

cabo nuevamente en el servidor de base de datos host. El ID de usuario y contraseña son ci

Manejando clientes no conﬁables

Si la máquina de servidor o de gateway tienen la autenticación en CLIENT, esto implica que se e

• Clientes no conﬁables: Como se describió arriba

Cuando la autenticación está conﬁgurada en CLIENT

Tabla 2. Autenticación tras comando connect o attach

¿Se suministró TRUST_ALLCLNTS TRUST_CLNTAUTH Cl

+ Yes Yes CLIENT CL