Las mejores prácticas de seguridad de IBM i comienzan con la configuración de los valores del sistema que regulan la facilidad o la dificultad con la que un tercero puede utilizar o hacer uso indebido del sistema. Cuando esos valores están mal configurados o no son controlados, se genera un riesgo de seguridad inaceptable.

Ejemplo

• Nivel QSECURITY

Muchos otros valores del sistema relacionados con la restauración de objetos suelen quedar en su nivel por defecto, reflejando la configuración típica de “carga y ejecución” de IBM i.

Esos valores del sistema están diseñados para funcionar en conjunto como un filtro que evita la restauración de objetos maliciosos o corrompidos, pero los valores por defecto de IBM i no ofrecen esta protección y, por lo tanto, el sistema podría quedar vulnerable.

Los profesionales de IT necesitan permisos especiales para administrar servidores. Además de cambiar la configuración delsistema, estos permisos podrían habilitar la capacidad de lectura o modificación de aplicaciones financieras, datos sobre tarjetas de crédito de los clientes y archivos confidenciales de los empleados.

Estos permisos especiales pueden ser muy peligrosos en manos de un usuario descuidado, negligente o malintencionado.

Los problemas de seguridad relacionados con usuarios y contraseñas son muy importantes porque representan la manera más obvia y sencilla de comprometer a su sistema.

Si no cuenta con medidas de seguridad apropiadas para usuarios y contraseñas, los esfuerzos que pueda realizar para asegurar otras áreas de la red IBM i serán, en su gran mayoría, ineficaces.

Ejemplo

• Perfiles de usuario inactivos

• Contraseñas por defecto

• Longitud mínima de contraseñas

• Otras configuraciones de contraseñas

• Contraseñas Olvidadas y otros Intentos de inicio de sesión inválidos

En general, en los servidores que no son IBM i, los usuarios que no tienen permisos para ciertos objetos o tareas, no pueden tener acceso a ellos. Con IBM i, este no es el caso. Cada objeto cuenta con un permiso por defecto, conocido como *PUBLIC, que se aplica a usuarios no mencionados explícitamente.

Salvo que se le brinde algún otro permiso específico al usuario, otorgando o denegando el acceso, este podrá operar con el permiso predeterminado del objeto. Esto no parece ser un problema hasta que descubrimos que este valor predeterminado lo establece IBM inicialmente y es suficiente como para permitir que un usuario abra un programa y tenga acceso de lectura, modificación o eliminación de datos de un archivo.

Esta situación genera un riesgo de modificaciones no autorizadas en programas y cambios en bases de datos.

IBM ha estado agregando herramientas a su IBM i (AS/400) que posibilitan el acceso a datos desde otras plataformas, especialmente PCs. Muchos servicios reconocidos, como FTP, ODBC, JDBC y DDM están activos y listos para enviar datos por la red tan pronto como se enciende el ordenador. Cualquier usuario con un perfil en el sistema y permiso sobre los objetos puede tener acceso a datos críticos corporativos en su servidor IBM i (AS/400).

La forma tradicional de controlar el acceso a datos confidenciales y comandos avanzados era limitar el acceso a la línea de comandos a los usuarios finales. En el pasado, ese método era eficaz.

Además de configurar el perfil de usuario con limitaciones de acceso a línea de comandos, el menú de aplicaciones controlaba el acceso a datos de los usuarios y también cuándo podían ejecutar ciertos comandos. Sin embargo, cuando IBM abrió nuevas interfaces que brindan acceso a datos y la oportunidad de ejecutar comandos remotos, este enfoque dejó de ser tan eficaz.

Una de las funciones de seguridad más importantes de IBM i es su capacidad de registro de eventos relacionados con la seguridad en un centro de almacenamiento no modificable, o Registro de Auditoría de Seguridad (Security Audit Journal). Esta función le permite a las organizaciones determinar la fuente de eventos críticos de seguridad, incluso para poder saber información como: ¿Quién eliminó este archivo? o ¿Quién le otorgó a este usuario el permiso *ALLOBJ?

Si la organización obtiene esta información a tiempo podrá reaccionar inmediatamente ante un caso de seguridad, en lugar de encontrar la violación o filtración de datos después de que ya se haya ocasionado un daño significativo.

Uno de los temas de seguridad de IBM i más polémicos es el riesgo que plantean los virus. Aunque la infraestructura tradicional de la biblioteca y del objeto de IBM i se considera altamente resistente a virus, se sabe que otras estructuras de archivos dentro del Sistema Integrado de Archivos (IFS) son susceptibles de albergar archivos infectados que después pueden propagarse por toda la red.