Hay un proceso pequeño pero complicado con un nombre en apariencia inocente; ocurre en su organización con mucha más frecuencia de lo que se figura. ¿Puede adivinar cuál es? Se llama «Acceso a IT» (también conocido como «acceso de emergencia») y a los auditores les encanta.
Cuando se necesita acceso urgente a los sistemas de producción —por parte de empleados de IT, por ejemplo—, existe un proceso para tal fin.
Ponen su nombre en una página web titulada «acceso de emergencia», declaran el motivo por el que necesitan acceder y se les da acceso inmediata y oportunamente al delicado sistema de producción.
Allí, pueden arreglar errores, instalar actualizaciones de software o comprobar asuntos relativos a usuarios finales, como por ejemplo por qué no se puede imprimir un informe. A fin de evitar que se produzcan casos de actividad no autorizada, como el de que el empleado de IT utilice este acceso privilegiado para transferir dinero a su cuenta bancaria, el proceso incluye capacidades de supervisión exhaustiva y alertas sobre el uso delicado.
Garantizar accesos seguros a los de IT puede ser complicado
El problema aquí es la seguridad. En la mayoría de las organizaciones, encontrará resistencia por parte de dos grupos de personas cuando intente implementar accesos de emergencia: el personal de IT y el equipo de seguridad, encabezado por su responsable, el CISO.
El personal de IT procurará evitar este proceso porque los obliga a solicitar el acceso cada vez que lo necesitan. Hasta no hace tanto, nadie les exigía que solicitaran este acceso. Ahora y de repente, tienen que cumplimentar un formulario y esperar múltiples aprobaciones hasta recibir acceso.
Como es de esperar, este cambio molestará a algunos. Sin embargo, si el requisito proviene del equipo de auditoría, será fácil vencer esa resistencia. Puede simplemente decir «Bien, este es el requisito del auditor para cumplir con SOX; no nos queda otra».
El segundo grupo es más difícil de manejar. Los equipos de seguridad siempre insistirán en la «autenticación»: verificar que la persona que solicita el acceso es realmente un empleado y no un impostor (es decir, un hacker). También insistirán en obtener un flujo de aprobadores para cada acceso: desde el responsable directo del empleado hasta el propietario de los datos y, finalmente, el propio CISO.
Afirmarán que, si se quiere conceder acceso a cualquiera, este debe examinarse a conciencia y estar bien supervisado. Es cierto, qué duda cabe; el único problema es la cantidad de molestias que esto implica y cómo perjudicará las operaciones diarias.
Si hay que esperar un día entero por un acceso de emergencia para un trabajo de dos horas, ¿no es eso contraproducente?
Demasiada seguridad puede crear agujeros de seguridad
Muchas veces hemos visto empleados de IT honestos buscando alternativas al proceso de acceso de emergencia estándar porque era demasiado complicado. Nadie quiere esperar todo un día para cuando la tarea urge, y nadie quiere hacerse cargo de despertar al CIO (que estaba incluido como aprobador) a las dos de la madrugada para que revise un problema urgente debido a una situación con usuario final en Japón.
A continuación, les mostramos algunos ejemplos que hemos descubierto recientemente para evitar el proceso estándar:
- Utilizar una cuenta legítima para realizar el trabajo. En este caso, el empleado de IT le dirá a un compañero «Oye, ¿puedo usar tu cuenta por un par de minutos? Tan solo necesito comprobar algo para nuestro usuario en Japón y no tengo tiempo de esperar todo el día para una aprobación». El compañero, que entiende la molestia de la espera y lo urgente que es la tarea, dejará a su colega de IT utilizar su cuenta. Por supuesto, esta no es la forma correcta de proceder.
- Utilizar una cuenta de interfaz no segura. Algunas de las cuentas que se utilizan para las interfaces de datos se conceden con permisos muy amplios (por ejemplo, SAP_ALL) y los informáticos lo saben bien. A menudo, vemos el uso de cuentas de interfaz (cuentas de lotes) para llevar a cabo tareas en modo de diálogo por empleados reales, en lugar de su finalidad prevista. Cuando investigamos el caso, resulta que la causa era buena y bien intencionada; sencillamente, el empleado había cedido a las prisas.
- Utilizar métodos de programación para obtener altos niveles de autorización en los sistemas productivos. Aunque esto suena como un verdadero hackeo, sabemos por experiencia propia que el personal de IT (la mayoría de ellos son programadores) utilizan módulos de funciones internas y procedimientos de software para elevar sus permisos en SAP, llevar a cabo la tarea y luego reestablecer a la normalidad sus permisos.
Todas las situaciones anteriores pueden supervisarse 24 horas al día, 7 días a la semana.
Una alternativa viable
El primer paso para implementar un proceso de acceso para IT al que se le dé un uso correcto es comprender que si el proceso resulta demasiado complicado podría no cumplir su propósito.
El proceso debe ser seguro —pero no demasiado— y debe responder a minuciosamente a los requisitos de auditoría, sin que deje de ser lo más sencillo posible. De esta forma, los empleados sí lo utilizarán y usted se evitará lagunas de seguridad innecesarias. Siempre hay que pensar en el usuario final y hallar el equilibrio entre la simplicidad, la complejidad y los requisitos de auditoría.
Además, una vez esté satisfecho con los resultados y la gente emplee el proceso con éxito, no se olvide de supervisar las estadísticas de uso para ver si la gente sigue utilizándolo. De vez en cuando, debe verificar que el proceso sea lo más simple posible y que sigue en uso. Un proceso sólido y funcional en funcionamiento significa menos recursos gastados en las operaciones diarias, mayor nivel de seguridad y menos preparativos para la próxima auditoría.
¿Quiere saber más sobre la implementación de un procedimiento de acceso de emergencia robusto y fiable?
