Prácticas recomendadas de seguridad

Como precaución, no asigne roles de acceso permisivo, como WorkMgr4, desde el principio si no está completamente seguro de que el usuario necesita privilegios de trabajo y ejecución. Por ejemplo, la productividad de un trabajador del caso puede mejorar al ver ciertos reportes, pero esto significa que al trabajador del caso se le debe asignar el portal de gestor mediante la definición de su rol de acceso WorkMgr4 y la concesión del acceso a un portal de gerente. En su lugar, se puede agregar un dashboard al portal especializado del trabajador del caso.

Las reglas Rule-Access-Role-Object (Acceso de rol a objetos o ARO) no están versionadas. No es posible anular una regla ARO dentro de un ruleset diferente. Solo puede haber una instancia de una regla ARO basada en sus claves, pyAccessRole, y pyAccessToClass.

En lugar de actualizar Work-ARO para eliminar el privilegio de ejecución como predeterminado, se puede agregar una clase más específica, como la clase de grupo de trabajo, por ejemplo, FSG-Booking-Work. Dentro de ese nuevo ARO, se puede eliminar el privilegio de ejecución. El privilegio de ejecución se puede otorgar para el conjunto de tipos de casos que supervisa un gerente.

La ofuscación de las URL no es una garantía de que un atacante nunca pueda encontrar una forma de formar una URL que, si no está protegida por el sistema, le dé acceso a la información que el atacante no debería poder ver o, peor aún, le permita modificar la información del sistema.

Recuerde el dicho “la oscuridad no es seguridad”. Si no se debe permitir que un miembro de un determinado grupo de trabajo o alguien con una determinado rol de acceso principal cree tipos de casos, debe definir una política de autorización que impida explícitamente ese acceso. Ocultar pyCreateCaseMenu dentro de la sección pyPortalNavInner del portal de datos usando una regla de decisión no es la solución adecuada, aunque puede ser parte de la solución. Esto es cierto independientemente de que la regla de decisión esté comprobando un privilegio.

Una URL puede ser definida por cualquiera que pueda aprovechar QueryString (?pyActivity=doUIAction&action=createNewWork&className=) y pueda crear el caso a menos que se implemente una verdadera seguridad (a través de la autorización adecuada).

Alternativamente, el desarrollador puede usar las reglas de decisión para verificar si el usuario tiene un determinado rol o privilegio de acceso. Las reglas de verificación de seguridad de decisión son útiles cuando no existen mejores medios de aplicación o en combinación con la autorización adecuada para mejorar la experiencia del usuario.

No querrá estar en una situación en la que se deban aplicar reglas de decisión en cada situación que requiera cumplimiento. Hacerlo es igual a escribir código que contiene lógica if/else; cada vez que se inventa un nuevo valor “else”, la lógica if/else necesita una actualización. La forma orientada a objetos de hacer cumplir la seguridad es proteger el objeto al que se accede en última instancia, no todas las rutas que se toman para llegar al objeto.

Ejemplo:

Supongamos que un operador tiene acceso de lectura a un caso, pero no tiene acceso de ejecución. El usuario puede emitir una URL como la siguiente:

No se muestra ningún mensaje de error. En su lugar, la pantalla dice NoID y muestra un botón que dice Open in Review (Abrir en revisión).

Imagine que no quiere que esa persona vea el caso en el modo de revisión a menos que esa persona sea el propietario actual o la última persona en actualizar el caso. Simplemente impedir el acceso a la asignación no es suficiente. Esto se debe a que Assign-Read access = canPerform solo evita que se realice la asignación. No impide que se abra el caso asociado. El acceso también debe impedirse o permitirse en el nivel de caso.

Observe la configuración de RBAC a continuación para FSG-Booking-Work. La regla de decisión de acceso pxRelatedToMe le permite al caso abrirse solo cuando el operador actual lo haya actualizado o resuelto por última vez o si actualmente es propiedad del operador actual. No se le permite a un compañero de trabajo abrir el caso.

En la aplicación Booking, el rol de acceso principal para ejecutivos de ventas debe clonarse o, mejor aún, depender de PegaRULES:User4. La siguiente imagen muestra lo que sucede cuando SalesExecutive1@Booking intenta abrir un caso propiedad de SalesExecutive2@Booking después de la modificación.

La opción Bulk Actions (Acciones en bloque) está presente en el menú de operador del portal de gerente de casos y de trabajador de casos. Si el requerimiento es que no se debe permitir que un Coordinador de instalaciones cree un Caso de evento, y no ha configurado la política de autorización adecuada, entonces el Coordinador de instalaciones puede usar la opción Bulk Actions (Acciones en bloque) para crear el caso de la siguiente manera:

Paso 1:

Paso 2:

Pega ha definido varias áreas para revisar antes de implementar una aplicación en producción. Cada conducto del gerente de implementación incluye un paso de revisión de seguridad para recordarles a los arquitectos esta tarea esencial. Las pautas de seguridad se incluyen en la regla de la guía de aplicación de pxApplicationSecurityChecklist, que se puede iniciar desde la Documentation pestaña de la regla de la aplicación.

Para obtener más detalles, consulte la Lista de comprobación de seguridad.

Para obtener más información sobre el diseño de la seguridad, consulte el seminario web sobre la excelencia en seguridad.