Descripción general de los sistemas ERP de SAP
Para las organizaciones que emplean sistemas de planificación de recursos empresariales (ERP) de SAP, este suele ser uno de los sistemas más críticos en los que operan. Recopila y cumple con los pedidos de los clientes, solicita pagos y les da seguimiento, y entrega datos financieros a ejecutivos e inversionistas. En resumen, es la columna vertebral de los negocios. Si un sistema ERP de SAP se cae o la seguridad se ve comprometida, el negocio puede detenerse.
A pesar de su importancia, algunos entornos de ERP de SAP aún necesitan alinearse mejor con los estándares de seguridad Zero Trust, empleados con frecuencia por soluciones modernas en la nube y de SaaS. Esto suele deberse a la flexibilidad de SAP, que implica que no hay dos implementaciones idénticas, y los cambios a menudo requieren mucho esfuerzo especializado.
Como arquitecto de identidad con una vasta experiencia en seguridad de SAP desde varios puntos de vista diferentes, puedo ofrecer una perspectiva sobre cómo las implementaciones de sistemas ERP de SAP pueden modernizarse para aprovechar los beneficios más recientes en materia de seguridad.
Problemas y desafíos comunes
Antes de analizar el estado futuro, hablemos de algunas de las áreas comunes que presentan las mayores oportunidades de mejora.
Nomenclatura y terminología
Cuando se trabaja con un proveedor tan grande como SAP, lograr que la terminología y la nomenclatura sean correctas puede ser un desafío. Me costó encontrar un título apropiado para este blog porque quería asegurarme de que me refería a la tecnología SAP correcta.
SAP ofrece una amplia variedad de productos, y algunas de las ofertas más recientes siguen modelos diferentes de los que abarcaré aquí. En esta publicación, cuando me refiero a sistemas ERP de SAP, estoy hablando del conjunto de productos que SAP ha creado y expandido desde 1972. Normalmente, se puede identificar este conjunto con algunas palabras clave: ABAP, S4/HANA, ECC, Basis o Netweaver.
Autenticación heredada
A pesar de los avances de SAP en la tecnología web de la IU, todavía es común que las organizaciones accedan a SAP a través del cliente tradicional de Windows, conocido como SAPGUI. Si bien la autenticación Zero Trust es posible para SAPGUI (hablaremos al respecto más adelante), es difícil de implementar y configurar. Como resultado, muchas organizaciones siguen usando contraseñas para la autenticación.
Con las contraseñas surgen todos los desafíos conocidos: una experiencia de usuario deficiente, la necesidad de herramientas de sincronización de contraseñas y métodos de autenticación poco seguros.
Sin embargo, la mayor preocupación no es la experiencia de usuario, sino el posible riesgo de seguridad. En SAPGUI, el cifrado de red está estrechamente relacionado con la autenticación. En muchas implementaciones, esto significa que los nombres de usuario y las contraseñas viajan a través de la red interna en texto sin formato. Si se utilizan herramientas de sincronización de contraseñas, esto también puede exponer las contraseñas de Active Directory. Finalmente, si el modo híbrido de Entra ID está habilitado, el mismo riesgo podría extenderse a las credenciales de Entra.
Usar una VPN o habilitar la autenticación de Windows puede ayudar a reducir parte de este riesgo, pero no son soluciones completas. Una verdadera estrategia de Zero Trust da por sentado que la red está en riesgo y aplica una autenticación fuerte en cada capa sin depender únicamente de las protecciones basadas en la red.
Proyectos incompletos de RBAC y desviación de la configuración
El modelo de autorización de SAP es altamente detallado y complejo. En mis primeros años como administrador, tuve que estudiar el curso ADM940 de SAP sobre seguridad y autorizaciones. No fue una lectura liviana, pero me enseñó cómo funcionan las características de seguridad de SAP.
A menudo, se piensa en la seguridad de SAP en términos de códigos de transacción (tcodes), cada uno asociado con una tarea empresarial. Sin embargo, detrás de cada acción del usuario, se verifican decenas o incluso cientos de autorizaciones dispersas. Estas verificaciones de autorización pueden ser diferentes según las condiciones del usuario o la versión de SAP que se esté implementando (hablaremos de esto más adelante).
La complejidad es un aspecto, pero la escala es otro. Ahora que quedó establecida la complejidad de los roles dentro de SAP, hablemos de la escala. Muchos proyectos de control de acceso basado en roles (RBAC) enfrentan obstáculos al intentar cubrir la totalidad del acceso para el caso de roles dedicados. Este objetivo poco realista puede conducir a una relación casi equivalente entre el número de usuarios y roles. Si bien este problema no es específico de las implementaciones de SAP, se manifiesta de varias maneras, lo que puede complicar un entorno de SAP.
SAP brinda herramientas para gestionar roles que sirven si se aplican de manera uniforme. Sin embargo, en muchos entornos, esa uniformidad no es común. Lo que funciona en un sistema SAP no suele funcionar de la misma manera en otros lugares.
Como resultado, muchas organizaciones usan métodos de poca seguridad para asignar acceso:
- Copiar de un usuario existente (SAP incluso tiene esta función incorporada en su modelo).
- Asignación de acceso en función de códigos de transacción (T-Codes). Estos códigos son un método simplista para determinar el nivel de acceso de un rol determinado.
Ambos enfoques acarrean desafíos. Modelar a los usuarios basándose en personal preexistente conlleva el riesgo de propagar accesos inadecuados que podrían haberse acumulado con el tiempo. Los códigos de transacción solo ofrecen una visión parcial de lo que un usuario puede hacer. Además, existe una idea equivocada y muy difundida de que estos códigos se pueden asignar directamente, lo cual no es posible. Por último, los módulos SAP más nuevos no se basan en códigos de transacción, por lo que este método se está volviendo obsoleto poco a poco.
Un camino que ya conocemos
No es ninguna sorpresa que se hayan empleado varias soluciones a este problema en el pasado (y que todavía se usen). Este es un ejemplo de cómo los productos de gestión de identidades y gobernanza de la identidad se han utilizado para proporcionar soluciones parciales:
Resumen de componentes
Nota: Estoy usando a propósito términos genéricos para estos componentes; muy a menudo, los productos de identidad cumplen una o más de estas funciones.
Servicio de directorio empresarial
Este componente es responsable de los servicios de control de acceso durante el tiempo de ejecución. Para situaciones en las que se produce la autenticación local de SAP, aquí es donde se sincronizaría la contraseña del usuario. Para situaciones en las que el SSO está configurado en SAP, este servicio proporcionaría los servicios de autenticación de Kerberos heredados.
Servicio de aprovisionamiento empresarial
Este componente es responsable de realizar el control de acceso basado en roles y el aprovisionamiento de acceso en todo el entorno. Este servicio ayuda a garantizar que las cuentas de usuario correctas estén configuradas en los sistemas correctos, y que el acceso correcto esté configurado en esas cuentas (incluido el servicio de directorio).
Módulo de GRC de SAP
Este módulo tiene muchos propósitos, incluidos la toma de control del aprovisionamiento automatizado de SAP del servicio de aprovisionamiento global, la ejecución del escaneo de segregación de funciones y la obtención de las aprobaciones de acceso adecuadas para cualquier acceso a SAP que se solicite.
Si bien este diseño puede ayudar a cumplir con los requisitos normativos, presenta algunos desafíos que podrían limitar el éxito de la implementación.
- Las aprobaciones para el acceso a SAP son completamente diferentes de las de otras aplicaciones empresariales. Esto se traduce en diferentes sistemas de auditoría, diferentes motores de flujo de trabajo para administradores y diferentes procesos de autorización para aprobadores. También puede generar una experiencia de usuario confusa, en la que los usuarios tienen problemas para entender lo que sucede si los aprobadores no autorizan las tareas rápidamente.
- El servicio de aprovisionamiento empresarial tiene una visibilidad limitada del acceso que existe en cada sistema SAP. Si bien el sistema de GRC de SAP tiene mecanismos confiables para sincronizar datos entre sí mismo y cada sistema SAP, el hecho de que el sistema empresarial no tenga acceso directo al sistema de registro puede dificultar la identificación y el seguimiento de los errores de sincronización cuando ocurren.
- Generalmente, este diseño no permite la colaboración entre el acceso durante el tiempo de ejecución que controla el servicio de directorio y el acceso en reposo que gestiona el servicio de aprovisionamiento. Por ejemplo:
- ¿Qué sucede si necesitamos otorgar acceso temporal durante solo una hora?
- ¿Qué pasa si queremos que la autenticación cambie según el nivel de acceso que tenga un usuario?
- ¿Qué sucede si necesitamos una autenticación fuerte para los usuarios avanzados de SAP en comparación con aquellos que tienen acceso limitado?
En este modelo, dos plataformas separadas controlan dos tipos diferentes de acceso. Como resultado, los casos de uso de la estrategia de Zero Trust como estos normalmente solo pueden integrarse mediante una orquestación compleja y frágil, que no es compatible de forma nativa.
Una mejor manera
En Okta, nuestra visión es permitir que cualquier organización utilice cualquier tecnología de forma segura. Esto significa que SAP, como componente crítico para cualquier organización que lo use, debe gestionarse de forma estandarizada para poder implementar una estrategia de Zero Trust en toda la empresa.
Resumen de componentes
Okta Platform
Okta proporciona gestión de identidades, gobernanza de la identidad y servicios de acceso privilegiado en toda la empresa. Ayuda a garantizar que las identidades se sincronicen y gestionen correctamente de acuerdo con las políticas. Ofrece una sola experiencia de solicitud y autorización de acceso, una sola experiencia de certificación de acceso y, por último, una sola plataforma de autenticación sensible al contexto para la organización.
GRC de SAP
Para implementaciones de SAP más grandes y centradas en el cumplimiento, el sistema de GRC de SAP desempeña un papel fundamental. Proporciona las capacidades de análisis detallado de segregación de funciones necesarias para ayudar con los requisitos normativos. A esta capacidad se suma la experiencia en el rubro que SAP puede brindar mejor que nadie. ¿Qué constituye un acceso inadecuado? ¿Qué acceso se contrapone con qué otro acceso? Esas preguntas están profundamente arraigadas en el dominio del producto de SAP, y nadie mejor que SAP para responderlas. Yo diría que este conjunto de reglas es uno de los componentes más valiosos del sistema de GRC de SAP.
Si bien el sistema de GRC desempeña un papel importante en esta arquitectura, funciona más como una API y una herramienta administrativa, no como algo con lo que los usuarios finales o los aprobadores suelen interactuar.
Este diagrama ejemplifica, en términos generales, los roles y responsabilidades de Okta y el sistema de GRC en este patrón de implementación recomendado.
En la superficie, esta estrategia tiene algunos beneficios claros para usuarios finales y para la gestión:
- Un sistema es responsable de todas las tareas de sincronización de identidades en toda la empresa.
- Hay un solo proceso de aprobación, de solicitud y de auditoría para toda la empresa.
- Se mantienen los controles de seguridad críticos de SAP.
- Las plataformas centrales de auditoría reciben la información más reciente directamente de los sistemas de SAP, sin posibilidad de errores intermedios.
En términos generales, se trata de usar la herramienta adecuada para el trabajo adecuado. Sin embargo, hoy en día, operamos en un mundo donde la identidad es sinónimo de seguridad, y Okta le brinda una estructura de seguridad de identidad que convierte las herramientas de identidad en herramientas de seguridad.
Es posible que haya escuchado el término “plataforma de identidad convergente”. Es reconocido por líderes y analistas de la industria. Cuando se pone en práctica, el concepto puede beneficiar la seguridad no solo de su implementación de SAP, sino también de toda su empresa.
Anteriormente, mencioné dos tipos de acceso: “en reposo” y “durante el tiempo de ejecución”.
- El acceso “en reposo” se refiere a usuarios, cuentas, derechos y roles que se configuran en toda la empresa. En SAP, esto representa sus registros maestros de usuario y sus asignaciones de roles. Me refiero a este acceso como “en reposo” porque es relativamente estable y no considera ningún contexto de tiempo de ejecución cuando las comprobaciones de autorización de SAP lo evalúan.
- El acceso “durante el tiempo de ejecución” es lo que ocurre cuando un usuario realmente intenta hacer algo. ¿En qué dispositivo está? ¿Cuál es la postura de ese dispositivo? ¿De qué red proviene? ¿Hay algo anormal en su comportamiento? ¿Cómo se autenticó y hace cuánto tiempo?
Para una verdadera estrategia de Zero Trust profunda y realmente protectora, ambos tipos de acceso deben funcionar juntos. No es suficiente con que un usuario tenga acceso, sino que solo debe usarlo en las condiciones correctas.
Al reunir todo esto en una sola plataforma, como Okta, puede aplicar estas capas de seguridad de manera escalable. El resultado es un enfoque moderno de Zero Trust que ayuda a garantizar que su entorno de SAP esté protegido con el mismo rigor que el resto de su infraestructura crítica.
Resumen
Si sigue aquí, le agradezco por su tiempo. Mi objetivo con esta publicación era aclarar tres ideas principales:
- Una breve descripción de las oportunidades de modernización de identidad disponibles para los clientes de SAP en la actualidad.
- Un análisis de por qué los enfoques tradicionales y aislados pueden limitar la implementación de un verdadero modelo de seguridad de vanguardia.
- Un enfoque de diseño moderno que utiliza las fortalezas de SAP, incluidas sus características de seguridad, mientras conecta SAP con los programas de seguridad empresarial más amplios que muchas organizaciones están desarrollando en la actualidad.
Si desea obtener más información sobre cómo se ve una plataforma de identidad convergente en la práctica, consulte aquí nuestro seminario web más reciente.
Estos materiales y las recomendaciones que contienen no constituyen asesoramiento legal, de privacidad, de seguridad, de cumplimiento ni empresarial. Estos materiales están destinados únicamente a fines informativos generales, y es posible que no reflejen los desarrollos legales, de seguridad y de privacidad más recientes, ni todos los temas relevantes. Usted es responsable de obtener asesoramiento legal, de seguridad, de privacidad, de cumplimiento o empresarial de su propio abogado u otro asesor profesional, y no debe confiar en las recomendaciones en estos materiales. Okta no se hace responsable ante usted de ninguna pérdida o daño que pueda resultar de la implementación de las recomendaciones de estos materiales. Okta no hace declaraciones ni ofrece garantías u otras seguridades con respecto al contenido de estos materiales. Puede encontrar la información sobre las garantías contractuales de Okta a sus clientes en okta.com/agreements.
Este blog no representa necesariamente la posición, las estrategias ni la opinión de Okta.
