Guía de conceptos de Microsoft BHOLD Suite

Microsoft Identity Manager 2016 (MIM) permite a las organizaciones administrar todo el ciclo de vida de las identidades de usuario y sus credenciales asociadas. Se puede configurar para sincronizar identidades, administrar de forma centralizada certificados y contraseñas y aprovisionar usuarios en sistemas heterogéneos. Con MIM, las organizaciones de TI pueden definir y automatizar los procesos usados para administrar identidades desde la creación hasta la retirada.

Microsoft BHOLD Suite amplía estas funcionalidades de MIM agregando el control de acceso basado en rol. BHOLD permite a las organizaciones definir roles de usuario y controlar el acceso a aplicaciones y datos confidenciales. El acceso se basa en lo que es adecuado para esos roles. BHOLD Suite incluye servicios y herramientas que simplifican el modelado de las relaciones de roles dentro de la organización. BHOLD asigna esos roles a derechos y para comprobar que las definiciones de roles y los derechos asociados se aplican correctamente a los usuarios. Estas funcionalidades están totalmente integradas con MIM, lo que proporciona una experiencia perfecta para los usuarios finales y el personal de TI por igual.

Esta guía le ayuda a comprender cómo funciona BHOLD Suite con MIM y trata los temas siguientes:

• Control de acceso basado en roles
• Atestación
• Informes
• Conector de administración de acceso

No se recomienda BHOLD para nuevas implementaciones. Microsoft Entra ID ahora proporciona revisiones de acceso, que reemplazan las características de campaña de atestación de BHOLD y la administración de derechos, que reemplaza las características de asignación de acceso.

Control de acceso basado en roles

El método más común para controlar el acceso de los usuarios a los datos y las aplicaciones es a través del control de acceso discrecional (DAC). En las implementaciones más comunes, cada objeto significativo tiene un propietario identificado. El propietario tiene la capacidad de conceder o denegar el acceso al objeto a otros usuarios en función de la identidad individual o la pertenencia a grupos. En la práctica, la DAC suele dar lugar a una gran cantidad de grupos de seguridad, algunos que reflejan la estructura organizativa, otros que representan agrupaciones funcionales (como tipos de trabajo o asignaciones de proyectos) y otros que constan de colecciones de usuarios y dispositivos que están vinculados con fines más temporales. A medida que crecen las organizaciones, la pertenencia a estos grupos es cada vez más difícil de administrar. Por ejemplo, si un empleado se transfiere de un proyecto a otro, los grupos que se usan para controlar el acceso a los recursos de proyectos deben actualizarse manualmente. En tales casos, no es raro que se produzcan errores, errores que pueden impedir la seguridad o la productividad del proyecto.

MIM incluye características que ayudan a mitigar este problema al proporcionar control automatizado sobre la pertenencia a la lista de grupos y distribución. Sin embargo, esto no aborda la complejidad intrínseca de la proliferación de grupos que no están necesariamente relacionados entre sí de forma estructurada.

Una manera de reducir significativamente esta proliferación es implementar el control de acceso basado en rol (RBAC). RBAC no desplaza la DAC. RBAC se basa en DAC proporcionando un marco para clasificar usuarios y recursos de TI. Esto le permite hacer explícita su relación y los derechos de acceso adecuados según esa clasificación. Por ejemplo, mediante la asignación a atributos de usuario que especifican el título del trabajo de los usuarios y las asignaciones de proyecto, se puede conceder al usuario acceso a las herramientas necesarias para el trabajo del usuario y los datos que el usuario necesita para contribuir a un proyecto determinado. Cuando el usuario asume un trabajo diferente y diferentes asignaciones de proyecto, al cambiar los atributos que especifican el título de trabajo del usuario y los proyectos se bloquea automáticamente el acceso a los recursos solo necesarios para la posición anterior de los usuarios.

Dado que los roles se pueden incluir dentro de roles de forma jerárquica (por ejemplo, los roles de administrador de ventas y representante de ventas se pueden incluir en el rol más general de ventas), es fácil asignar derechos adecuados a roles específicos y, sin embargo, proporcionar derechos adecuados a todos los usuarios que comparten también el rol más inclusivo. Por ejemplo, en un hospital, a todo el personal médico se le podría dar derecho a ver los registros de los pacientes, pero solo a los médicos (un suplente del rol médico) se les podría dar derecho a introducir recetas para el paciente. Del mismo modo, a los usuarios que pertenecen al rol administrativo se les podría denegar el acceso a los registros de pacientes, excepto a los empleados de facturación (un subrol del rol administrativo), a los que se les podría conceder acceso a aquellas partes de los registros que son necesarias para facturar al paciente por los servicios prestados por el hospital.

Una ventaja adicional de RBAC es la capacidad de definir y aplicar la separación de tareas (SoD). Esto permite a una organización definir combinaciones de roles que conceden permisos que no deben tener el mismo usuario, de modo que un usuario determinado no pueda asignar roles que permitan al usuario iniciar un pago y autorizar un pago, por ejemplo. RBAC proporciona la capacidad de aplicar dicha directiva automáticamente en lugar de tener que evaluar la implementación efectiva de la directiva por usuario.

Objetos de modelo de roles de BHOLD

Con BHOLD Suite, puede especificar y organizar roles dentro de su organización, asignar usuarios a roles y asignar los permisos adecuados a los roles. Esta estructura se denomina modelo de rol y contiene y conecta cinco tipos de objetos:

• Unidades organizativas
• Usuarios
• Funciones
• Permisos
• APLICACIONES

Unidades organizativas

Las unidades organizativas (OrgUnits) son los medios principales por los que los usuarios se organizan en el modelo de roles de BHOLD. Cada usuario debe pertenecer al menos a un OrgUnit. (De hecho, cuando se quita un usuario de la última unidad organizativa de BHOLD, el registro de datos del usuario se elimina de la base de datos BHOLD).

Aunque no es necesario, en la mayoría de los casos las unidades organizativas se estructuran en BHOLD para representar la estructura jerárquica de la organización real, similar a la siguiente:

En este ejemplo, el modelo a seguir sería la unidad organizativa de la corporación en su totalidad (representada por el presidente, ya que el presidente no forma parte de ninguna unidad organizativa), o se podría utilizar la unidad organizativa raíz de BHOLD (que siempre existe) para ese propósito. OrgUnits que representan las divisiones corporativas dirigidas por los vicepresidentes se colocarían en la unidad organizativa corporativa. A continuación, las unidades organizativas correspondientes a los directores de marketing y ventas se agregarían a las unidades organizativas de marketing y ventas, y las unidades organizativas que representan a los gerentes de ventas regionales se colocarían en la unidad organizativa del administrador de ventas de la región este. Los asociados de ventas, que no administran otros usuarios, se harían miembros de la unidad organizativa del administrador de ventas de la región este. Tenga en cuenta que los usuarios pueden ser miembros de una unidad organizativa en cualquier nivel. Por ejemplo, un asistente administrativo, que no es administrador e informa directamente a un vicepresidente, sería miembro de la unidad organizativa del vicepresidente.

Además de representar la estructura organizativa, las unidades organizativas también se pueden usar para agrupar usuarios y otras unidades organizativas según criterios funcionales, como para proyectos o especialización. En el diagrama siguiente se muestra cómo se usarían las unidades organizativas para agrupar asociados de ventas según el tipo de cliente:

En este ejemplo, cada asociado de ventas pertenecería a dos unidades organizativas: una que representa el lugar del asociado en la estructura de administración de la organización y otra que representa la base de clientes del asociado (comercial o corporativa). A cada unidad organizativa se le pueden asignar roles diferentes que, a su vez, se pueden asignar permisos diferentes para acceder a los recursos de TI de la organización. Además, los roles se pueden heredar de las unidades organizativas primarias, lo que simplifica el proceso de propagación de roles a los usuarios. Por otro lado, se puede impedir que se hereden roles específicos, lo que garantiza que un rol específico solo esté asociado a las unidades organizativas adecuadas.

OrgUnits se puede crear en BHOLD Suite mediante el portal web de BHOLD Core.

Usuarios

Como se indicó anteriormente, cada usuario debe pertenecer al menos a una unidad organizativa (OrgUnit). Dado que las unidades organizativas son el mecanismo principal para asociar un usuario con roles, en la mayoría de las organizaciones un usuario determinado pertenece a varios OrgUnits para facilitar la asociación de roles con ese usuario. Sin embargo, en algunos casos, puede ser necesario asociar un rol a un usuario aparte de cualquier OrgUnits al que pertenezca el usuario. Por lo tanto, un usuario se puede asignar directamente a un rol, así como obtener roles de orgUnits a los que pertenece el usuario.

Cuando un usuario no está activo dentro de la organización (mientras está fuera por licencia médica, por ejemplo), el usuario se puede suspender, lo que revoca todos los permisos del usuario sin eliminar al usuario del modelo de roles. Al volver al deber, el usuario se puede reactivar, lo que restaura todos los permisos concedidos por los roles del usuario.

Los objetos para los usuarios se pueden crear individualmente en BHOLD a través del portal web de BHOLD Core o mediante el Access Management Connector con el Servicio de Sincronización de FIM para importar la información de usuario de servicios como Active Directory Domain Services o aplicaciones de recursos humanos.

Los usuarios se pueden crear directamente en BHOLD sin usar el servicio de sincronización FIM. Esto puede ser útil al modelar roles en un entorno de preproducción o prueba. También puede permitir que los usuarios externos (como los empleados de un subcontratista) tengan roles asignados y, por tanto, tener acceso a los recursos de TI sin agregarse a la base de datos de empleados; sin embargo, estos usuarios no podrán usar las características de autoservicio de BHOLD.

Funciones

Como se indicó anteriormente, en el modelo de control de acceso basado en rol (RBAC), los permisos se asocian a roles en lugar de a usuarios individuales. Esto permite conceder a cada usuario los permisos necesarios para realizar las tareas del usuario cambiando los roles del usuario en lugar de conceder o denegar por separado los permisos de usuario. Como consecuencia, la asignación de permisos ya no requiere la participación del departamento de TI, sino que se puede realizar como parte de la administración de la empresa. Un rol puede agregar permisos para acceder a diferentes sistemas, ya sea directamente o mediante el uso de subinroles, lo que reduce aún más la necesidad de participación de TI en la administración de permisos de usuario.

Es importante tener en cuenta que los roles son una característica del propio modelo RBAC; Normalmente, los roles no se aprovisionan para las aplicaciones de destino. Esto permite que RBAC se use junto con las aplicaciones existentes que no están diseñadas para usar roles o para cambiar las definiciones de roles se adapten a las necesidades de cambiar los modelos de negocio sin tener que modificar las propias aplicaciones. Si una aplicación de destino está diseñada para usar roles, puede asociar roles en el modelo de roles de BHOLD con los roles de aplicación correspondientes tratando los roles específicos de la aplicación como permisos.

En BHOLD, puede asignar un rol a un usuario principalmente a través de dos mecanismos:

• Al asignar un rol a una unidad organizativa (unidad organizativa) de la que el usuario es miembro
• Mediante la asignación de un rol directamente a un usuario

Opcionalmente, sus unidades organizativas miembro pueden heredar un rol asignado a una unidad organizativa primaria. Cuando una unidad organizativa asigna o hereda un rol, se puede designar como un rol efectivo o propuesto. Si es un rol efectivo, a todos los usuarios de la unidad organizativa se les asigna el rol. Si se trata de un rol propuesto, debe activarse para que cada usuario o unidad organizativa miembro sea efectiva para los miembros de ese usuario o unidad organizativa. Esto permite asignar a los usuarios un subconjunto de los roles asociados a una unidad organizativa, en lugar de asignar automáticamente todos los roles de la unidad organizativa a todos los miembros. Además, los roles se pueden asignar fechas de inicio y finalización, y se pueden colocar límites en el porcentaje de usuarios dentro de una unidad organizativa para la que un rol puede ser efectivo.

En el diagrama siguiente se muestra cómo se puede asignar un rol a un usuario individual en BHOLD:

En este diagrama, el rol A se asigna a una unidad organizativa como un rol heredable, y así lo heredan sus unidades organizativas miembro y todos los usuarios de esas unidades organizativas. El rol B se asigna como un rol propuesto para una unidad organizativa. Debe activarse para que un usuario de la unidad organizativa pueda autorizarse con los permisos del rol. El rol C es un rol efectivo, por lo que sus permisos se aplican inmediatamente a todos los usuarios de la unidad organizativa. El rol D está vinculado directamente al usuario y, por tanto, sus permisos se aplican inmediatamente a ese usuario.

Además, se puede activar un rol para un usuario en función de los atributos de un usuario. Para obtener más información, consulte Autorización basada en atributos.

Permisos

Un permiso en BHOLD corresponde a una autorización importada desde una aplicación de destino. Es decir, cuando BHOLD está configurado para trabajar con una aplicación, recibe una lista de autorizaciones que BHOLD puede vincular a roles. Por ejemplo, cuando Active Directory Domain Services (AD DS) se agrega a BHOLD como una aplicación, recibe una lista de grupos de seguridad que, como permisos de BHOLD, se pueden vincular a roles de BHOLD.

Los permisos son específicos de las aplicaciones. BHOLD proporciona una sola vista unificada de permisos para que los permisos se puedan asociar a roles sin necesidad de que los administradores de roles comprendan los detalles de implementación de los permisos. En la práctica, los distintos sistemas podrían aplicar un permiso de forma diferente. El conector específico de la aplicación desde el servicio de sincronización FIM a la aplicación determina cómo se proporcionan los cambios de permisos para un usuario a esa aplicación.

APLICACIONES

BHOLD implementa un método para aplicar el control de acceso basado en rol (RBAC) a aplicaciones externas. Es decir, cuando BHOLD se aprovisiona con usuarios y permisos de una aplicación, BHOLD puede asociar esos permisos a los usuarios mediante la asignación de roles a los usuarios y, a continuación, vincular los permisos a los roles. Después, el proceso en segundo plano de la aplicación puede asignar los permisos correctos a sus usuarios en función de la asignación de roles o permisos en BHOLD.

Desarrollo del modelo de roles de BHOLD Suite

Para ayudarle a desarrollar el modelo de roles, BHOLD Suite proporciona generador de modelos, una herramienta que es fácil de usar y completa.

Antes de usar el generador de modelos, debe crear una serie de archivos que definan los objetos que usa el generador de modelos para construir el modelo de roles. Para obtener información sobre cómo crear estos archivos, consulte Referencia técnica de Microsoft BHOLD Suite.

El primer paso para usar el generador de modelos BHOLD consiste en importar estos archivos para cargar los bloques de creación básicos en el generador de modelos. Cuando los archivos se hayan cargado correctamente, puede especificar criterios que usa el generador de modelos para crear varias clases de roles:

• Roles de pertenencia asignados a un usuario en función de orgUnits (unidades organizativas) a los que pertenece el usuario
• Roles de atributo asignados a un usuario en función de los atributos del usuario en la base de datos BHOLD
• Roles propuestos que están vinculados a una unidad organizativa, pero que deben activarse para usuarios específicos
• Roles de propiedad que conceden a un usuario control sobre unidades organizativas y roles para los que no se especifica un propietario en los archivos importados

Después de crear estos roles en el modelo de roles, puede exportar el modelo de roles a la base de datos BHOLD en forma de archivo XML.

Características avanzadas de BHOLD

En las secciones anteriores se describen las características básicas del control de acceso basado en rol (RBAC) en BHOLD. En esta sección se describen características adicionales de BHOLD que pueden proporcionar mayor seguridad y flexibilidad a la implementación de RBAC de la organización. En esta sección se proporcionan información general sobre las siguientes características de BHOLD:

• Cardinalidad
• Separación de funciones
• Permisos adaptables al contexto
• Autorización basada en atributos
• Tipos de atributos flexibles

Cardinalidad

La cardinalidad hace referencia a la implementación de reglas de negocio diseñadas para limitar el número de veces que dos entidades se pueden relacionar entre sí. En el caso de BHOLD, se pueden establecer reglas de cardinalidad para roles, permisos y usuarios.

Puede configurar un rol para limitar lo siguiente:

• El número máximo de usuarios para los que se puede activar un rol propuesto
• Número máximo de subroles que se pueden vincular al rol
• Número máximo de permisos que se pueden vincular al rol

Puede configurar un permiso para limitar lo siguiente:

• Número máximo de roles que se pueden vincular al permiso
• Número máximo de usuarios a los que se puede conceder el permiso

Puede configurar un usuario para limitar lo siguiente:

• Número máximo de roles que se pueden vincular al usuario
• Número máximo de permisos que se pueden asignar al usuario a través de asignaciones de roles

Separación de funciones

La separación de tareas (SoD) es un principio empresarial que busca evitar que los individuos obtengan la capacidad de realizar acciones que no deben estar disponibles para una sola persona. Por ejemplo, un empleado no debe poder solicitar un pago y autorizar el pago. El principio de SoD permite a las organizaciones implementar un sistema de comprobaciones y saldos para minimizar su exposición al riesgo de errores de empleado o mala conducta.

BHOLD implementa SoD al permitirle definir permisos incompatibles. Cuando se definen estos permisos, BHOLD aplica SoD evitando la creación de roles vinculados a permisos incompatibles, ya sea vinculados directamente o a través de la herencia, y evitando que los usuarios tengan asignados varios roles que, cuando se combinan, concederían permisos incompatibles, de nuevo mediante la asignación directa o a través de la herencia. Opcionalmente, los conflictos se pueden invalidar.

Permisos adaptables al contexto

Al crear permisos que se pueden modificar automáticamente en función de un atributo de objeto, puede reducir el número total de permisos que tiene que administrar. Los permisos adaptables al contexto (CSP) permiten definir una fórmula como un atributo de permiso que modifica cómo aplica el permiso la aplicación asociada al permiso. Por ejemplo, puede crear una fórmula que cambie el permiso de acceso a una carpeta de archivos (a través de un grupo de seguridad asociado a la lista de control de acceso de la carpeta) en función de si un usuario pertenece a una unidad organizativa (unidad organizativa) que contiene empleados de contrato o tiempo completo. Si el usuario se mueve de una unidad organizativa a otra, se aplica automáticamente el nuevo permiso y se desactiva el permiso anterior.

La fórmula CAP puede consultar los valores de los atributos que se han aplicado a aplicaciones, permisos, unidades organizativas y usuarios.

Autorización basada en atributos

Una manera de controlar si un rol vinculado a una unidad organizativa (unidad organizativa) se activa para un usuario determinado de la unidad organizativa es usar la autorización basada en atributos (ABA). Con ABA, puede activar automáticamente un rol solo cuando se cumplen determinadas reglas basadas en los atributos de un usuario. Por ejemplo, puede vincular una función a una unidad organizativa que se active para un usuario solo si el título del puesto del usuario coincide con el título del puesto en la regla de ABA. Esto elimina la necesidad de activar manualmente un rol propuesto para un usuario. En su lugar, se puede activar un rol para todos los usuarios de una unidad organizativa que tengan un valor de atributo que satisfaga la regla de ABA del rol. Las reglas se pueden combinar para que un rol se active solo cuando los atributos de un usuario cumplan todas las reglas de ABA especificadas para el rol.

Es importante tener en cuenta que los resultados de las pruebas de reglas de ABA están limitados por la configuración de cardinalidad. Por ejemplo, si la configuración de cardinalidad de una regla especifica que no se pueden asignar más de dos usuarios a un rol y, si una regla de ABA activaría un rol para cuatro usuarios, el rol solo se activará para los dos primeros usuarios que superen la prueba de ABA.

Tipos de atributos flexibles

El sistema de atributos de BHOLD es muy extensible. Puede definir nuevos tipos de atributo para objetos como usuarios, unidades organizativas (unidades organizativas) y roles. Los atributos se pueden definir para tener valores que son enteros, booleanos (sí/no), alfanuméricos, fecha, hora y direcciones de correo electrónico. Los atributos se pueden especificar como valores únicos o una lista de valores.

Atestación

BHOLD Suite proporciona herramientas que puede usar para comprobar que a los usuarios individuales se les han concedido los permisos adecuados para realizar sus tareas empresariales. El administrador puede usar el portal proporcionado por el módulo de atestación de BHOLD para diseñar y administrar el proceso de atestación.

El proceso de atestación se lleva a cabo mediante campañas en las que los administradores de campañas tienen la oportunidad y medios para comprobar que los usuarios para los que son responsables tienen acceso adecuado a las aplicaciones administradas por BHOLD y los permisos correctos dentro de esas aplicaciones. El propietario de una campaña está designado para supervisar la campaña y asegurarse de que la campaña se está llevando a cabo correctamente. Se puede crear una campaña para que se produzca una vez o de forma periódica.

Normalmente, el administrador de una campaña será un administrador que atestiguará los derechos de acceso de los usuarios que pertenecen a una o varias unidades organizativas para las que el administrador es responsable. Los encargados se pueden seleccionar automáticamente para los usuarios que participan en una campaña en función de los atributos de usuario, o los encargados de una campaña se pueden definir enumerándolos en un archivo que asigna a cada usuario que participa en la campaña a un encargado.

Cuando comienza una campaña, BHOLD envía un mensaje de notificación por correo electrónico a los administradores y propietarios de la campaña y, a continuación, envía recordatorios periódicos para ayudarles a mantener el progreso en la campaña. Los administradores se dirigen a un portal de campaña donde pueden ver una lista de los usuarios para los que son responsables y los roles asignados a esos usuarios. Después, los administradores pueden confirmar si son responsables de cada uno de los usuarios enumerados y aprobar o denegar los derechos de acceso de cada uno de los usuarios enumerados.

Los propietarios de campañas también usan el portal para supervisar el progreso de la campaña y las actividades de campaña se registran para que los propietarios de la campaña puedan analizar las acciones que se realizaron en el transcurso de la campaña.

Informes

El módulo BHOLD Reporting le ofrece la posibilidad de ver información en el modelo de roles a través de una variedad de informes. El módulo BHOLD Reporting proporciona un amplio conjunto de informes integrados, además de que incluye un asistente que puede usar para crear informes personalizados básicos y avanzados. Al ejecutar un informe, puede mostrar inmediatamente los resultados o guardarlos en un archivo de Microsoft Excel (.xlsx). Para ver este archivo con Microsoft Excel 2000, Microsoft Excel 2002 o Microsoft Excel 2003, puede descargar e instalar el paquete de compatibilidad de Microsoft Office para formatos de archivo de Word, Excel y PowerPoint.

El módulo BHOLD Reporting se usa principalmente para generar informes basados en la información de rol actual. Para generar informes para auditar los cambios en la información de identidad, Forefront Identity Manager 2010 R2 tiene una funcionalidad de informes para el servicio FIM que se implementa en el almacenamiento de datos de System Center Service Manager. Para obtener más información sobre los informes de FIM, consulte la documentación de Forefront Identity Manager 2010 y Forefront Identity Manager 2010 R2 en la biblioteca técnica de Forefront Identity Management.

Entre las categorías cubiertas por los informes integrados se incluyen las siguientes:

• Administración
• Atestación
• Controles
• Control de acceso entrante
• Registro
• Modelo
• Estadísticas
• Flujo de trabajo

Puede crear informes y agregarlos a estas categorías, o bien definir sus propias categorías en las que puede colocar informes personalizados e integrados.

Mientras crea un informe, el asistente le guiará a través del proceso de suministrar los siguientes parámetros:

• Identificación de información, como el nombre, la descripción, la categoría, el uso y la audiencia
• Campos que se van a mostrar en el informe
• Consultas que especifican qué elementos se van a analizar
• Orden en el que se van a ordenar las filas
• Campos usados para dividir el informe en secciones
• Filtros para refinar los elementos que se devuelven en el informe

En cada fase del asistente, puede obtener una vista previa del informe tal como lo ha definido hasta ahora y guardarlo si no necesita especificar parámetros adicionales. Puede también volver a los pasos anteriores para cambiar los parámetros que especificó anteriormente en el asistente.

Conector de administración de acceso

El módulo BHOLD Suite Access Management Connector admite la sincronización inicial y continua de datos en BHOLD. El conector de gestión de acceso funciona con el servicio de sincronización FIM para mover datos entre la base de datos de BHOLD Core, el metaverso de MIM y las aplicaciones de destino y los almacenes de identidades.

Las versiones anteriores de BHOLD requerían varios agentes de administración para controlar el flujo de datos entre MIM y las tablas de base de datos intermedias de BHOLD. En BHOLD Suite SP1, Access Management Connector le permite definir agentes de administración (MAs) en MIM que proporcionan transferencia de datos directamente entre BHOLD y MIM.

Pasos siguientes

• guía de instalación de BHOLD
• Referencia de BHOLD para desarrolladores
• Historial de versiones de BHOLD