Como profesionales de la seguridad, es interesante reflexionar sobre lo que realmente nos quita el sueño: los datos de los clientes, los entornos de producción y el acceso al código fuente. Y la pregunta es: ¿qué lugar de la lista ocupan los sistemas de RR. HH. y finanzas?
Todos estamos de acuerdo en que son importantes, por supuesto. Sin embargo, para muchos de nosotros con formación técnica, a menudo pasan a un segundo plano. Tal vez sea porque apreciamos más la complejidad de los sistemas en nuestro “ámbito”, o tal vez porque esperamos que se comporten como un mosaico más en el portal de SSO, integrándose bien con nuestro proveedor de identidad.
Ahora bien, Workday no es simplemente otra aplicación. De hecho, el modelo de seguridad de Workday se extiende más allá de muchos de los límites que comúnmente consideramos para las aplicaciones SaaS. Tiene su propio modelo de seguridad poderoso, complejo y, a menudo, invisible que se ejecuta internamente (por una buena razón) y puede configurarse incorrectamente de maneras que su IdP nunca verá.
Y sí, es un objetivo muy valioso y también un objetivo habitual, como estamos viendo actualmente. Contiene datos confidenciales de personas: información de identificación personal, nóminas, cuentas bancarias y el organigrama de toda la empresa. Los informes del estado de Nueva Jersey, de la universidad de Brown y de la universidad de Washington muestran una tendencia preocupante: los atacantes están aprovechando activamente los controles de identidad débiles para cambiar la información de depósitos directos. Esto les permite robar las nóminas del personal y acceder fácilmente a los fondos.
Analicemos algunos de los desafíos únicos que implica proteger Workday y cómo podemos superarlos de una vez por todas.
La brecha del ciclo de vida: cuando los usuarios existen antes y después del empleo
Para la mayoría de las aplicaciones SaaS, el acceso suele estar ligado al ciclo de vida del usuario dentro de la empresa (incorporación, movimiento y baja). Workday echa por tierra la mayoría de estos supuestos.
El ciclo de vida del usuario de Workday se extiende más allá del cronograma típico que va de la contratación al despido. Los exempleados necesitan acceder para recuperar documentos fiscales (como los formularios W-2) y los talones de pago de las liquidaciones finales. A los empleados precontratados a menudo también se les concede acceso para completar las tareas de incorporación. Esto crea rutas de acceso permanentes que omiten la gestión del ciclo de vida estándar de su IdP. Por una razón similar, el acceso a estas cuentas se realiza fuera del SSO empresarial normal, y se usa en su lugar una combinación de nombre de usuario y contraseña (con o sin MFA).
Cuando se gestiona correctamente, esto funciona bien, y Workday, de hecho, brinda herramientas específicas para este propósito, como el grupo de seguridad Terminee as Self. Sin embargo, esto echa por tierra muchos supuestos que se aplican a la mayoría de las aplicaciones SaaS y puede ocasionar brechas graves si no se configura correctamente.
Por ejemplo, al considerar la mayoría de las aplicaciones SaaS, cuando la aplicación está configurada para redirigir al proveedor de identidad en los intentos de autenticación, ya no hay forma de autenticarse directamente en ella. En Workday, sin embargo, por las razones descritas anteriormente, aún es posible acceder a la página de autenticación local evitando el SSO (por ejemplo, wd5.myworkday.com/company/login.htmld?redirect=n). Si las credenciales se gestionan incorrectamente o esta ruta de inicio de sesión nativa no tiene la MFA aplicada dentro de Workday, se puede abrir una brecha que omite la seguridad de su IdP principal. Un atacante con una contraseña filtrada puede entrar sin obstáculos.
Un laberinto de permisos
El modelo de permisos de Workday es muy granular y potente, y está diseñado en torno a roles y procesos empresariales. Esto es necesario para la función que cumple, pero está diseñado y gestionado por los equipos de RR. HH. y finanzas, lo que implica que suele ser un punto ciego para los equipos de TI y seguridad.
No tener visibilidad de esta estructura de permisos esenciales y no saber qué roles con privilegios existen ni quién los posee implica que no hay capacidad para razonar adecuadamente sobre cómo protegerlos.
Este problema se agrava por la existencia de usuarios del sistema de integración (ISU, la terminología de Workday para las cuentas de servicio). Estas cuentas presentan desafíos importantes:
- Quién puede crearlos. A menudo, la delegación de derechos de creación de ISU no está clara.
- Qué privilegios tienen. Hay demasiados permisos que se acumulan con el tiempo.
- Quién posee las credenciales. Existe acceso compartido o no gestionado a las claves de la cuenta de servicio.
Esto puede ocasionar un problema generalizado de “administrador en la sombra”. Puede que un usuario que necesitaba acceso especial para un proyecto único hace tres años siga teniéndolo. Estos riesgos pueden durar años sin la capacidad de identificarlos o sanearlos, hasta que quedan expuestos por una filtración.
Políticas de autenticación tan complejas como su IdP
Muchas aplicaciones SaaS están configuradas con una política de autenticación simple: “delegar en el proveedor de identidades”. Workday, sin embargo, contiene su propio motor de políticas de autenticación enriquecido y complejo, que aplica sus propias reglas sobre quién puede entrar.
Workday permite que las decisiones de acceso contextual se tomen de forma nativa. Puede crear reglas basadas en la ubicación de la red, la postura del dispositivo y los roles del usuario, y basarse en ellos para permitir o denegar los tipos y métodos de autenticación.
Esto tiene sentido en situaciones como las siguientes:
- Ciclos de vida extendidos del usuario. Exempleados que acceden a los formularios W-2 y empleados precontratados que están completando su incorporación.
- Acceso sensible al contexto. Restricción de los usuarios de wifi público solo a las tareas de autoservicio.
- Entornos de varios IdP. Organizaciones que utilizan modelos de identidad de concentrador y radio.
Sin duda, poder configurar tales políticas no es algo malo. Pero la existencia de esas políticas fuera de la visibilidad del equipo de seguridad, y el escrutinio reducido que podría aplicarse a ellas en comparación con las del proveedor de identidad, puede crear riesgos de seguridad si la configuración es incorrecta. Por ejemplo, una política destinada a ser utilizada para usuarios fuera de la fuerza laboral, y que permita el acceso sin usar el SSO, podría aplicarse accidentalmente también a otros usuarios.
De la reactividad a la proactividad: proteger Workday con Okta ISPM
Esto nos lleva al problema detrás de todos estos problemas: no se puede proteger lo que no se puede ver.
La tarea de proteger a toda la organización requiere una visibilidad clara de Workday. Eso significa comprender el modelo de seguridad en el que se basa, ejecutar informes, auditar permisos e incluso analizar las políticas de autenticación.
Este desafío de visibilidad es exactamente lo que resuelve Okta Identity Security Posture Management (ISPM). En lugar de dejar a los equipos de seguridad sin visibilidad de la estructura de permisos interna de Workday, ISPM supervisa continuamente su inquilino, lo que transforma el complejo laberinto de identidad de Workday en un panel único.
Su postura de seguridad pasa de ser reactiva a proactiva porque puede hacer lo siguiente:
- Eliminar los puntos ciegos. ISPM proporciona una vista integral de cada identidad. No solo ve “usuarios activos”, sino que también supervisa a los exempleados (que ya fueron desvinculados), a los usuarios locales que no se originan en el proveedor de identidad y a los usuarios del sistema de integración (ISU) automatizados. Esto asegura que las rutas de acceso permanente no pasen inadvertidas.
- Aplicar el “privilegio mínimo”. ISPM identifica las cuentas con demasiados privilegios, tanto de usuarios humanos como de ISU, mediante el análisis del acceso que tienen a dominios de datos específicos. Esto permite detectar aquellas cuentas de servicio con derechos de administrador de hace tres años y revocarles el acceso antes de que se conviertan en un riesgo.
- Detectar y proteger las identidades no humanas. ISPM detecta automáticamente las cuentas de servicio y los usuarios del sistema de integración (ISU) creados por humanos en Workday. ISPM muestra inmediatamente qué acceso tienen y detecta credenciales sin rotar, permisos elevados y cuentas inactivas.
- Reducir la superficie de ataque. ISPM indica automáticamente las cuentas con políticas de autenticación débiles (por ejemplo, contraseñas antiguas o ausencia de MFA) e identifica las cuentas no utilizadas o huérfanas que representan un riesgo de seguridad inmediato.
El resultado final es un entorno de Workday altamente seguro, compatible y continuamente supervisado.
¿Quiere eliminar los puntos ciegos de identidad en todas sus aplicaciones más críticas?
Ya está disponible el acceso anticipado a la integración de Workday con ISPM. Comuníquese con su representante de Okta para saber cómo ISPM puede aportar información de seguridad moderna a su infraestructura de identidad más crítica. Obtenga más información en okta.com/products/identity-security-posture-management.
