HelpSystems Blog

Las 10 peores prácticas en Seguridad de IBM i, según Carol Woodbury

Muchas empresas cometen los mismos errores cuando gestionan la Seguridad de IBM i. Sin embargo, su corrección es simple y proporciona grandes mejoras a la protección de sus sistemas. En esta entrada, Carol Woodbury, Vice-Presidente de Servicios de Seguridad Global de HelpSystems, comparte cuáles son las 10 prácticas que más le molestan en relación a la Seguridad de IBM i.

1. Administradores con contraseñas que nunca expiran

Las reglas de contraseñas, incluyendo el período de expiración (la frecuencia con la que se solicita que una contraseña sea modificada), es uno de los puntos a controlar cuando se realiza una Evaluación de Riesgo, además de chequear que esos intervalos no hayan sido ignorados a nivel de perfil de usuario. Es apropiado poseer cuentas de servicio con contraseñas que no expiran, pero no es correcto contar con perfiles de usuario que puedan iniciar sesión con una contraseña que no expira. Para Carol, lo más molesto es ver una cuenta de administrador con contraseñas que no expiran. Estas cuentas son algunas de las más poderosas del sistema. Si se ven comprometidas, el perfil puede ser utilizado o ser objeto de abuso para siempre.

La solución: ¡Los administradores deben cambiar sus contraseñas!

2. Otorgar permiso *ALL, en lugar del realmente necesario

Los perfiles de aplicaciones, en especial aquellos que ejecutan conexiones ODBC o JDBC con IBM i para acceder a archivos de base de datos, necesitan permisos sobre el archivo para ser capaces de leerlo o actualizarlo. El problema es cuando un administrador (generalmente un administrador de sistemas o responsable de aplicaciones) otorga el permiso *ALL para este perfil, en lugar de otorgar solo la autorización requerida, lo que hace que éste pueda acceder al archivo de base de datos o directorio que se está escribiendo.

Por ejemplo, si un archivo debe ser leído, el perfil de aplicación solo requiere un permiso *USE. Con un *ALL, la aplicación puede borrar y modificar registros, borrar el archivo, o autorizar a otros a acceder al archivo. Lo mismo sucede cuando se concede *ALL a un directorio. Si la aplicación solo necesita escribir un archivo en un directorio, el perfil de aplicación solo necesita el permiso *W. La capacidad de leer el contenido del directorio, limpiar el directorio o conceder otros accesos, no debe ser otorgada. Esta práctica no solo es un riesgo de Seguridad, sino que hace que sea muy difícil modificar los accesos más tarde. Por lo general, el personal familiarizado con el proceso ya no está en la compañía, por lo que es necesario intentar determinar qué está haciendo el proceso y luego utilizar el método prueba-error para conocer cuál es el permiso requerido realmente.

La solución: Los administradores deben determinar, en la etapa inicial de configuración de procesos, cuáles son los permisos necesarios. No conceda *ALL a cualquier perfil que requiere acceso.

3. Conceder todos los permisos especiales a cuentas de servicio

Esta es una leve variación del punto anterior. Consiste en asignar todos los permisos especiales a las cuentas de servicio, sin importar si realmente lo necesitan para realizar sus tareas. Muchas cuentas de servicio se utilizan para realizar conexiones entre IBM i y otro servidor o con los archivos FTP. En estos casos, no hay necesidad de que un perfil reciba permisos especiales. Los usuarios que realizan esas tareas simplemente necesitan permisos a los archivos que deben acceder. Proporcionar, ciegamente, a todas las cuentas de servicio todos los permisos especiales, solo porque son cuentas de servicio, representa un riesgo de Seguridad incluso mayor que el del punto 2, debido a que la mayoría de las cuentas de servicio tienen contraseñas que no expiran y que suelen ser conocidas por varios individuos. Otorgar más permisos a estos usuarios (usualmente programadores) de los que corresponde, les proporciona acceso a un perfil poderoso.

La solución: ¡Deje de otorgar permisos especiales a perfiles que no lo necesitan!

4. El valor de sistema QCRTAUT establecido en *ALL.

Al igual que otorgar *ALL en lugar de solo los permisos necesarios, cambiar el valor de sistema QCRTAUT (crear permiso) tiene el mismo efecto. Establecer el valor de sistema QCRTAUT para *ALL significa que el permiso *PUBLIC de los objetos nuevos que se creen será establecido para *ALL. Una vez más, este es un riesgo de Seguridad importante ya que cualquier usuario en el sistema tiene el permiso para leer, modificar y borrar objetos. Una vez establecido *ALL, es muy difícil volver a cambiarlo a un valor más restrictivo, ya que es difícil prever si algo se romperá. Para la mayoría de los objetos, esto no es un inconveniente. Los problemas suelen ocurrir cuando se accede a un archivo de base de datos. Uno puede pensar que el permiso *CHANGE en un archivo de base de datos puede ser suficiente. Sin embargo, el proceso de agregar un miembro de archivo físico requiere *CHANGE además del permiso *OBJMGT. A menos que alguien conozca profundamente estos procesos, es imposible saber qué permisos adicionales hacen falta antes de comenzar a probarlos.

La solución: Por favor, evite cualquier tentación de establecer QCRTAUT para *ALL.

5. La auditoría no está configurada

Cuando un sistema no tiene la auditoría configurada, la excusa suele ser que como nunca ha pasado nada, no hace falta molestarse con la auditoría. Pero, si su empresa no audita, ¿cómo sabe que no ha pasado nada?

Otra excusa suele ser: "No tenemos tiempo para mirar todos los registros de auditoría, entonces ¿para qué hacerlo?".  La respuesta, incluso si no tiene pensado revisar su journal de auditoría con frecuencia, es que necesita contar con los registros en caso de que sean necesarios para una investigación. Carol recuerda cuántas veces fue convocada para investigar una filtración de datos, solo para darse cuenta de que el cliente había eliminado todos los receptores del journal de auditoría, el historial de logs, y los registros de tareas, de modo que no había nada para revisar en búsqueda de un comportamiento inapropiado.

La solución: Habilite la auditoría, incluso si no tiene intenciones de revisar la actividad regularmente.

6. Dejar perfiles inactivos en el sistema

Si un perfil está en el sistema, se deben considerar las implicaciones de su Seguridad. Por ejemplo, si un perfil tiene permisos especiales excesivos, deberían ser removidos. Pero si el perfil está inactivo, ¿por qué no simplemente eliminar el perfil, en lugar de ocuparse en remover los permisos?

Lo mismo aplica a los perfiles que tienen contraseñas por defecto. Si el perfil tiene una contraseña que es la misma que el nombre de usuario, pero nunca ha sido utilizado o no ha sido utilizado en los últimos 90 días, ¿por qué molestarse en hacer algo con esa contraseña? Simplemente elimine el perfil del sistema. Los perfiles de empleados que ya no están en la compañía deben sí o sí ser eliminados para evitar la posibilidad de que éstos mantengan el acceso.

Además, los perfiles inactivos suman tiempo innecesario al proceso de Almacenamiento de Datos de Seguridad (SAVSECDTA) y, aún peor, agregan tiempo adicional al proceso de Restaurar Perfil de Usuario (RSTUSRPRF), en caso de que el sistema tenga que ser reconstruido.

La solución: En algunos sistemas existen miles de perfiles inactivos. Este es un enorme riesgo de Seguridad y un desperdicio de los recursos del sistema.

7. Los perfiles inactivos que deben permanecer en el sistema debido a malas prácticas de programación

En muchos casos, los administradores no tienen más opción que dejar los perfiles en el sistema, aunque estén inactivos, porque cuando se genera un reporte histórico de la actividad de la aplicación de un usuario, la descripción del usuario se toma del parámetro de campo texto del perfil de usuario. Si el perfil es eliminado del sistema, ese texto dirá "Usuario no encontrado". ¿Qué programador en su sano juicio programaría un archivo histórico sin mantener la historia completa (el campo texto del usuario) y confiaría solamente en el perfil que permanece indefinidamente en el sistema?

Otro escenario que preocupa a Carol es cuando la existencia de un perfil se utiliza para verificar si un usuario puede ejecutar una aplicación. No se valida una combinación de ID de usuario y contraseña, sino solo la presencia de un perfil en el sistema. En este caso, el campo “última fecha de uso” del perfil, no está actualizado. Entonces, para el sistema, el perfil aparece como inactivo ya que su última fecha de uso nunca se actualizó. Sin embargo, si usted elimina el perfil, el usuario ya no puede acceder a los datos.

La solución: Erradique estas prácticas de programación

8. Los proveedores requieren el uso de QSECOFR

El perfil de usuario QSECOFR debe ser utilizado solo para actualizaciones de sistema, no para inicios de sesión regulares o cualquier tarea diaria. Para Carol, un gran error es cuando los proveedores requieren que los administradores de aplicaciones se registren con QSECOFR para instalar o configurar su aplicación. Esto solo significa pereza por parte del proveedor, y no existe absolutamente ninguna necesidad de solicitar este permiso.

La solución: Sea exigente con sus proveedores

9. Los proveedores requieren demasiados permisos para ejecutar sus aplicaciones

Algunos proveedores requieren que los usuarios de su aplicación tengan asignado a su perfil *ALLOBJ y otros permisos especiales, incluso si la aplicación ejecuta funciones que no los necesitan. El problema es que los proveedores no pueden determinar cuáles son los permisos especiales que son realmente necesarios, algo que provoca que las organizaciones tengan excesivos permisos especiales asignados sin razón.

La solución: Sea exigente con sus proveedores

10. Los proveedores no se hacen cargo

Antes, era bastante sencillo asegurar los datos de aplicaciones. Los proveedores solamente tenían que explicar a los administradores cómo configurar los perfiles de usuarios de aplicaciones para que fueran al menú correcto de la aplicación. Entre eso y garantizar que los perfiles estuvieran configurados con capacidades limitadas (LMTCPB) - *YES, los datos estaban protegidos. No existía tecnología que permitiera un acceso directo a los datos. En ese entonces no importaba el permiso que los proveedores establecieran sobre los objetos de aplicaciones, ni en los archivos de bases de datos. Sin embargo, esos días terminaron, y ahora sí es importante saber cuáles son las configuraciones de permisos, ya que existe una gran cantidad de métodos que permiten acceder a datos y al menú.

Carol ha escuchado muchas quejas en relación a la apertura de las configuraciones establecidas por los proveedores para los objetos de aplicaciones. Desafortunadamente, no se trata simplemente de cambiar la configuración de Seguridad de la aplicación. Si, de repente, luego de una actualización, el proveedor cambia de un permiso *PUBLIC *ALL en los archivos de su aplicación a *PUBLIC *EXCLUDE, todos los procesos que utilizan protocolos como ODBC, DDM, y FTP pueden dejar de funcionar debido a fallas en los permisos. Nadie estará contento con ese resultado. Sin embargo, lo que puede pasar es que los proveedores comiencen a enviar sus aplicaciones en una forma que simplifique la protección de los datos y proporcionen orientación a sus clientes sobre cómo lograr el acceso de solo lectura o denegado por defecto para los archivos de base de datos de su aplicación.

Para Carol, es molesto ver a los proveedores que simplemente no se interesan por las preocupaciones de sus clientes sobre la seguridad de sus datos, o se niegan a proporcionar asistencia, y amenazan con eliminar el soporte si la configuración de Seguridad de su aplicación es modificada.

La solución: ¡Los proveedores necesitan preocuparse por la Seguridad de sus clientes!

Conclusiones

Estas situaciones son un problema porque exponen de manera innecesaria la Seguridad de IBM i y ponen en riesgo los datos críticos de su empresa. Dedique algunos minutos para analizar si alguna de estas prácticas ocurre en su compañía y tome las medidas necesarias para modificarla.