Modelos de autorización

Las aplicaciones de Pega suelen reunir a muchas personas (roles de usuario) para realizar el trabajo. Los roles incluyen clientes, trabajadores del centro de llamadas, gerentes y administradores. La mayoría de los usuarios cumplen uno de los roles aplicables a una aplicación determinada. El RBAC define las acciones que un rol está autorizado a realizar según la clase, entre otros:

• Acciones de clases: ejecutar actividades, ejecutar reportes
• Acciones de registros: abrir, modificar (crear y actualizar), eliminar
• Acciones específicas de reglas regidas por Privilegios

Revisión de los tipos de reglas de control de acceso basado en roles (RBAC)

Cada aplicación tiene roles distintos que forman la base para la autorización. Configure su RBAC mediante los siguientes tipos de reglas.

 " data-embed-button="image_browser" data-entity-embed-display="view_mode:media.embedded" data-entity-embed-display-settings="" data-entity-type="media" data-entity-uuid="6f1f7897-9469-4a30-bf47-54a73f53e67f">

• Access group (Grupo de acceso): colección de roles de acceso que, cuando se agregan, forman la cartera de control de acceso basada en roles para una sola persona (rol).
• Access role (Rol de acceso): colección de reglas de acceso de rol a objeto y acceso denegado que definen todas las configuraciones de control de acceso basadas en roles que rigen qué acceso se otorga (y deniega) a los usuarios a quienes se les asigna el rol de acceso.
• Access of Role to Object (ARO) (Acceso de rol a objeto): asociación de un rol de acceso a las operaciones que se otorga o deniega a los titulares de ese rol de acceso para realizar en un objeto (como una instancia de clase).
• Privilege (Privilegio): regla que se puede adjuntar a ciertos tipos de reglas (o partes de estas) para autorizar quién puede ejecutar la regla o parte de la regla. Por ejemplo:
  • Solo los titulares de un privilegio ApprovePR pueden realizar la acción de flujo Approve Purchase Request (Aprobar solicitud de compra).
  • Solo los titulares de un privilegio ShowPR pueden ver el elemento de menú Show Purchase Requests (Mostrar solicitudes de compra) configurado dentro de una regla de navegación.
• Class (Clase): el tipo de datos que está sujeto a autorización.
• Access When rule (Regla de decisión de acceso): regla que define el control de acceso condicional (como una regla de decisión normal) que normalmente evalúa una o más propiedades en la clase sujeta a autorización. La intención es que el resultado del control de acceso producido por la regla de decisión varíe entre diferentes instancias de la misma clase. Por ejemplo:
  • ¿El caso de solicitud de compra se encuentra actualmente en la etapa de aprobación?
  • ¿Es el salario del empleado mayor a USD 50 000?
• Access Deny rule (Regla de denegación de acceso): asociación de un rol de acceso a las operaciones que los titulares de ese rol de acceso tienen explícitamente denegado para realizar en un objeto.

Características recientes del RBAC

Las siguientes funciones surgieron en lanzamientos recientes de Pega Platform que influyen aún más en el control de acceso basado en roles. Los ejemplos de cada uno se analizan en módulos posteriores.

• Dependent roles (Roles dependientes): permiten que los roles de acceso se configuren y resuelvan en tiempo de ejecución en función de una jerarquía de dependencia de roles de acceso.
• Privilege inheritance (Herencia de privilegios): permite que los privilegios otorgados a una clase para un rol de acceso (por su ARO) incluyan los privilegios especificados en los ARO de sus superclases dentro del mismo rol de acceso.
• Short-circuited access checking (Comprobación de acceso en cortocircuito): los roles de acceso que producen un resultado explícito de otorgar o denegar pueden devolver este resultado de inmediato sin verificar los roles de acceso posteriores en el grupo de acceso cuando, particularmente en el caso de un otorgamiento explícito, la decisión de control de acceso eventual es conceder acceso.
• App Studio managed authorization (Autorización administrada de App Studio): App Studio proporciona una capacidad de configuración de autorización básica que complementa la base del RBAC proporcionada por Dev Studio. Para permitir que los citizen developers administren los roles de acceso, seleccione el checkbox Habilitar configuración de acceso a la página en App Studio en el grupo de acceso.

La importancia de los privilegios

Los privilegios brindan mayor seguridad, ya que se pueden usar para controlar el acceso a reglas individuales o a partes de reglas individuales.

Los privilegios son un componente fundamental de su estrategia de autorización, ya que brindan la oportunidad de autorizar explícitamente la ejecución de ciertas reglas "justo a tiempo". Los privilegios complementan las funciones de seguridad y control de acceso proporcionadas por los roles de acceso y las listas de rulesets, ya que restringen el acceso a reglas específicas en lugar de a clases completas o versiones de rulesets. Use privilegios para diferenciar las capacidades de diferentes grupos de usuarios dentro de su aplicación. Los privilegios pueden evitar la ejecución no deseada de una regla con el uso imprevisto de la aplicación.

Resolución de roles en tiempo de ejecución y herencia de privilegios

Cuando define las reglas de Acceso de rol a objeto (ARO) según la clase, Pega navega por la jerarquía de clases y determina el ARO más específico relativo a la clase del objeto para ese rol. Todos los ARO menos específicos en la jerarquía de clases para ese rol se omiten. La operación que se está realizando está permitida si el ARO más específico permite la operación. Si al operador se le otorgan múltiples roles, las reglas ARO más específicas se determinan para cada rol. Pega Platform realiza la operación si la operación está permitida en cualquiera de los ARO más específicos.

Como se indicó, los privilegios pueden proporcionar una seguridad más granular porque se definen en reglas individuales. Por ejemplo, para ejecutar una acción de flujo protegida por un privilegio, el usuario debe tener el privilegio. El privilegio se otorga a través de los ARO más específicos para la clase del objeto. Sin embargo, existe una opción sobre el rol para heredar privilegios dentro de los ARO definidos en la jerarquía de clases. Al seleccionar esta opción, se proporciona al operador todos los privilegios otorgados por los ARO que se definen para las clases en la jerarquía de clases del objeto.

En el siguiente ejemplo, el rol tiene seleccionada la opción de heredar privilegios. Si el usuario trabaja en un caso de reporte de gastos, los derechos de acceso se definen en la fila resaltada en negrita. Los privilegios adicionales se heredan de la jerarquía de clases (TGB-HRApps-Work y Work-).

Clase de acceso	Instancias de lectura	Instancias de escritura	Instancias de eliminación	Reglas de lectura	Reglas  de escritura	Reglas de eliminación	Reglas de ejecución	Actividades de ejecución	Privilegios
Work-	5	5		5			5	5	AllFlows(5) AllFlowActions(5)
TGB-HRApps-Work	5	5		5			5	5	ManagerReports(5)
TGB-HRApps-Work-ExpenseReport	5	5	5	5			5	5	SubmitExpenseReport(5)

ABAC complementa RBAC permitiendo que las políticas de control de acceso controlen el acceso a atributos específicos de un registro (siempre que RBAC haya concedido acceso al registro), independientemente de dónde se utilicen esos atributos en la aplicación (en una pantalla, en un reporte). También puede usar ABAC para definir el control de acceso de nivel de registro (adicional a RBAC), donde el rol que cumple el operador para la aplicación no determina las condiciones para acceder a esos registros.

	RBAC	ABAC
Reglas	Consulte el diagrama de RBAC en la sección anterior	Política de control de acceso (ACP) Condiciones de la política de control de acceso (ACPC) Decisión de acceso
Control	Abrir instancias Modificar instancias Eliminar instancias Abrir reglas Modificar reglas Eliminar reglas	Leer Descubrimiento Actualizar Eliminar Lectura de propiedad Cifrado de propiedad

ABAC es opcional y se usa junto con RBAC. ABAC compara la información del usuario con los datos de casos fila por fila o columna por columna. ABAC se configura mediante reglas de política de control de acceso que especifican el tipo de acceso y las reglas de condición de política de control de acceso que definen un conjunto de condiciones de política que comparan las propiedades del usuario u otra información en el portapapeles con las propiedades de la clase restringida.

Puede definir políticas de control de acceso para las clases que heredan de Assign-, Data- y Work- y utilizar la funcionalidad de herencia completa de Pega Platform. Las condiciones de la política de control de acceso se unen con una operación AND cuando existen varias políticas de control de acceso del mismo tipo en la ruta de herencia, con nombres diferentes. Solo se permite el acceso cuando se cumplen todas las condiciones definidas en la política de control de acceso.

En el siguiente ejemplo, si el usuario de la aplicación de Recursos Humanos desea actualizar un caso de compra, las condiciones para las políticas de control de acceso definidas en la jerarquía de clases se unen mediante AND. El usuario tiene acceso para actualizar el caso de compra solo si WorkUpdate AND HRUpdate AND HRPurchaseUpdate dan como resultado un valor verdadero.

Clase de acceso	Leer	Actualizar	Eliminar	Descubrimiento	PropertyRead	PropertyEncrypt
Work-	WorkRead	WorkUpdate		WorkDiscover
TGB-HR-Work		HRUpdate	HRDelete	HRDiscover	HRPropRead
TGB-HR-Work-Purchase	HRPurchaseRead	HRPurchaseUpdate			HRPurchasePropRead	HRPurhcasePropEncrypt

Si deshabilitó el ABAC en el pasado, puede habilitar ABAC actualizando los ajustes de Dynamic System Settings (Configuración dinámica del sistema):
 
Descripción breve: Enable Attribute-Based Security
Ruleset de propietario: Pega-RulesEngine
Propósito de configuración: EnableAttributeBasedSecurity
Valor: true
RS: Pega-ProcessCommander

Otra capacidad de control de acceso en Pega es el control de acceso basado en el cliente (CBAC). Esto se centra más en el seguimiento y el procesamiento de solicitudes para ver, actualizar o eliminar datos personales del Cliente que se encuentran en sus aplicaciones de Pega, como lo exigen las regulaciones del RGPD de la UE (y similares). No influye en las consideraciones de autorización para los System Architects líderes al diseñar una aplicación de Pega. Por otra parte, no se abarca en más detalle en este módulo.

Para obtener más información sobre el CBAC, consulte el artículo de Pega Community Definir reglas de control de acceso basadas en el cliente.