Archive for March, 2009

Objetos de Autorización: Transporte

Wednesday, March 25th, 2009

En este post vamos a describir los objetos de autorización relacionados con el sistema de transporte de SAP y dar una breve descripción de los mismos y sus posibilidades de configuración.

Principalmente los objetos de autorización que más nos van a interesar son:

S_TRANSPRT
Permite realizar tareas de creación, administración y visualización de órdenes de transporte, usualmente poseen distintos permisos al mismo los desarrolladores, parametrizadores, líderes, y administradores de transporte.

Los campos son Actividad (ACTVT) y Request Type (TTYPE) en base a los cuales podemos definir distintas actividades a realizar dependiendo del tipo de Orden (Request)

Las actividades son:

    01:  Agregar o Crear
    02: Modificar
    03: Visualizar
    05: Bloquear
    06: Borrar
    43: Libera
    50: Cambiar el mandante de origen
    60: Importar
    65: Reorganizar
    75: Liberar otras órdenes
    90: Cambiar Dueño

Los principales tipos de órden pueden ser (TTYPE):

    CLCP: Copia de Cliente
    CUST
    : Orden de Customizing
    DLOC
    : Orden local
    DTRA
    : Orden transportable
    MOVE
    : Relocation transports (all three types)
    TASK
    : Tareas
    TRAN
    : Transporte de Copias

De esta manera, si queremos definir solo permisos de visualización sobre las órdenes podemos establecer la actividad en 03 para todos los tipos de órden.

O configurar solo la modificación de tareas, o la liberación de las órdenes de customizing (CUST) o workbench (DTRA) de manera de que un rol solo pueda utilizar tareas previamente creadas y asignadas y el otro tenga el permiso de generar las órdenes y tareas, o reasignarlas.

El otro objeto que entra en juego en la administración es el S_CTS_ADMI
que posee un solo campo (CTS_ADMFCT) que representan tareas a las que se tiene permiso de ejecución. Estas pueden ser:

TABL - Modificación de rutas de transporte (importante resguardar esta autorización y no darla indiscriminadamente)

INIT – Iniciar el sistema de transporte después de una copia de mandante

SYSC – Permite definir el nivel de cambios en la transacción SCC1 y parametrizar el sistema de transporte

IMPT – Permiso de Import, aunque su uso ya no debiera aplicarse ya que existen códigos más especificos que detallamos a continuación.

IMPA - Importar todas las órdenes de transporte de la cola de import.

IMPS – Importar las órdenes de transporte al sistema destino individualmente.

INBX - Tratar el pool de trabajo de TMS Workflow

TADD - Transmitir órdenes de transporte a una cola de import (addtobuffer).

TDEL - Borrar órdenes de transporte de la cola de import.

TQAS - Activar o borrar ódenes de una cola de import

TADM -Ejecutar comandos del programa para control de transportes.

QTEA – Autorización para realizar transportes al sistema productivo.

En base a las mismas puede definirse una correcta segregación de funciones de las actividades diferenciándose al encargado de requerir el cambio, el que ejecuta la tarea, el que la libera en un ambiente, el que la importa en otro y así según las necesidades puntuales de control que la organización requiera.

VN:F [1.9.18_1163]
Rating: 4.0/5 (1 vote cast)
VN:F [1.9.18_1163]
Rating: 0 (from 0 votes)

Tips: Sistema de Transporte

Wednesday, March 18th, 2009

Existe un control poco conocido y utilizado en el sistema SAP que permite crear advertencias, o errores en el sistema de transporte si una orden modifica algún objeto definido como crítico. Es un útil sistema de control para hacer más simple y práctica, la revisión de las órdenes de transporte.

Para definir los objetos primero debemos asegurarnos que este chequeo esté activado en el perfil de transporte. El parámetro es CHK_CRIOBJ_AT_EXPORT y puede cambiarse su valor desde la transacción STMS - Resumen (documentación de sap), el valor 0 no realizara chequeo alguno, W crea un warning y por último E genera un error en caso de encontrar un objeto crítico e impide el transporte. La configuración ideal habitualmente es W, para alertar al usuario responsable de los transportes.

Los objetos críticos se definen también en la transacción STMS - Resumen, luego Detalles y Objetos Críticos.

Este control es de suma utilidad a la hora de ayudar a la siempre ardua tarea de controlar que lo transportes realizados en el sistema no comprometan la seguridad del mismo, o la confidencialida de la información que en el poseemos.

VN:F [1.9.18_1163]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.18_1163]
Rating: 0 (from 0 votes)

El sistema de transporte en SAP

Wednesday, March 18th, 2009

El sistema de transporte en la plataforma SAP es de suma importancia para nosotros, desde el punto de vista de la seguridad. A través del mismo nos garantizamos la separación de los ambientes, y el control de cambios. En el presente post vamos a hacer una introducción a los principales aspectos del mismo.

Mediante el sistema de transporte nosotros vamos a realizar el pasaje de datos, estructuras, programas, parametrizaciones, roles, etc. entre los distintos ambientes, a través de lo que en SAP se conocen como órdenes de transporte.

Un breve pantallazo sobre los ambientes lo vimos anteriormente aquí.

Las órdenes de transporte son la estructura en la que se almacena la información a transportar, las mismas están constituidas por tareas individuales (pueden tener una sola) las cuales deben asociarse a usuarios individuales, los cuales adjuntaran sus modificaciones en las mismas.

Cuando uno modifica un objeto en el sistema (ABAP, Customizing, etc) el tipo de objeto es seleccionado automáticamente y se solicita una orden de transporte la cual si uno posee los permisos puede crearla, o simplemente asignarla a una orden ya creada que tengamos asignada con su correspondiente tarea.

Siempre dependiente de los permisos que poseamos (S_CTS_ADMI) podríamos reasignar ordenes de otros usuarios, crear ordenes para otros usuarios, etc.

Una vez creada la orden o asignadas las modificaciones a una tarea, la misma debe liberarse para que sea incluida en la orden y la misma pueda procesarse, la documentación que se desee debe incluirse antes de liberar la tarea. A su vez la orden también necesita ser Liberada por la persona con la responsabilidad y los permisos adecuados para hacerlo, para poder realizar esta tarea deben estar todas las tareas de la misma liberadas.

Cuando la orden es liberada, el sistema se encarga de guardar el versionado de los objetos involucrados, desbloquear los objetos tomados por la orden, y guardados los archivos de datos en el directorio correspondiente del sistema operativo, a su vez se marca la orden como import en el sistema destino.

Dentro del “Transport Organizer” (SE09) se realizan todas las tareas de liberación y monitoreo de las órdenes. Adicionalmente puede utilizarse como sistema de consulta la transacción SE03.

Dentro del workflow de transporte debe incluirse la verificación de tablas, programas, y demás objetos modificados, para verificar que los cambios que se realizan no afectan la seguridad e integridad del sistema.

Los objetos de autorización que principalmente regulan el comportamiento del usuario respecto al sistema de transportes son el S_CTS_ADMI para las funciones administrativas y el S_TRANSPRT, en lo referente a las autorizaciones de crear, modificar y liberar órdenes y tareas.

Este post no trata de ser más que una introducción a la temática del sistema de transporte el cual es mucho más amplio y el cual en breve cubriremos con más información.

VN:F [1.9.18_1163]
Rating: 4.7/5 (3 votes cast)
VN:F [1.9.18_1163]
Rating: 0 (from 2 votes)

Proyectos: Metodología de Construcción de Roles en SAP

Thursday, March 12th, 2009

A lo largo de un proyecto de implementación de SAP o una reingeniería de la seguridad del sistema nos encontramos con distintas tareas a realizar para construir los roles que le sean funcionales a la organización.

En el presente post evaluaremos una alternativa metodológica para trabajar utilizada en varios proyectos exitosos de implementación de la seguridad de SAP.

image

El gráfico que vemos arriba representa el proceso completo el cual pasamos a detallar:

Etapa 1 – Identificación de Roles

Entradas: Mapa de Procesos de la organización

Tareas: Una vez que los procesos se encuentran modelados se comienzan a identificar las actividades indivisibles que pueden ser agrupadas en roles. A su vez sobre estos roles se realizar un primer análisis de segregación de funciones para detectar

Salidas: Mapas de procesos con roles asignados a las actividades.

Actores: Analistas de Procesos, Analistas Funcionales SAP, Usuarios Clave, Control Interno, Administración de Seguridad.

Etapa 2 – Selección de Transacciones

Entradas: Mapas de procesos con roles asignados a las actividades.

Tareas: Definición de transacciones necesarias para ejecutar las actividades definidas en el mapa de procesos. Armado de roles y análisis de Segregación de Funciones por código de transacción. Apertura de roles de negocio en roles del sistema de acuerdo a las necesidades de mantenimiento u optimización (agrupar actividades de visualización, incorporar reportes necesarios para ejecutar la actividad principal, etc.)

image

Salidas: Definición de roles del sistema con sus respectivas transacciones. Planilla de Roles, Transacciones y Objetos de Autorización a completar.

Actores: Analistas Funcionales SAP, Control Interno, Administración de Seguridad

image

Etapa 3 – Definición de Variantes

Entradas: Definición de roles del sistema con sus respectivas transacciones. Planilla de Roles, Transacciones y Objetos de Autorización a completar.

Tareas: Elaboración de una planilla de criterios de apertura por niveles organizativos u otras necesidades específicas. Definición de las necesidades de apertura basándose en la confidencialidad, requerimientos del negocio, distribución geográfica, y control interno. Construcción de las variantes.

Salidas: Variantes de rol construidas y listas para las pruebas.

Actores: Usuarios Clave Control Interno, Administración de Seguridad, Analistas Funcionales SAP (apoyo)

Etapa 4 – Prueba de Roles

Entradas: Roles y variantes construidos (al menos uno de prueba).

Tareas: Elaboración de los casos de pruebas positivas y negativas (que no tiene que poder hacer). Ejecución de las pruebas. Registración de resultados y corrección de errores.

Salidas: Roles Aceptados y Construidos.

Actores: Usuarios Clave, Control Interno, Administración de Seguridad, Analistas Funcionales SAP.

image

Etapa 5 – Asignación a Usuarios

Entradas: Planilla de Roles y Variantes (Puede comenzar el relevamiento de asignación antes de la finalización de la prueba)

Tareas: Relevamiento de asignación de usuarios a roles. Puede hacerse un relevamiento previo para validar el criterio de roles con el negocio, y luego abrirlo en las variantes respectivas. Análisis de Segregación de funciones en la asignación.

image

Salidas: Seguridad creada y documentada.

Actores: Usuarios Clave, Control Interno, Administración de Seguridad.

Comentarios sobre el proceso:

- Es de suma importancia incorporar una actividad anterior a todas estas etapas, involucrando a los participantes del proyecto desde el lado funcional, para comentarles como es el proceso, cual sería su participación y el grado en que deberán involucrarse en el proceso. Del éxito, y la comprensión de esta charla dependerá mucho el éxito final del proyecto.

- Las dos revisiones de segregación de funciones a lo largo del proyecto atacan problemas distintos. El primero trata que los roles en si mismos no contengan problemas de segregación, de ser así, la simple asignación del rol estaría dándole un problema al usuario al que se le asigna. Este caso no puede ocurrir nunca porque implicaría una mala definición del rol por parte de los responsables. La segunda revisión es ya para controlar que a un usuario no se le presenten problemas de segregación de funciones por poseer más de un rol y estos entren en conflicto entre sí, y es distinto al control anterior.

Espero que les sea útil el presente post y espero sus comentarios.

VN:F [1.9.18_1163]
Rating: 4.6/5 (7 votes cast)
VN:F [1.9.18_1163]
Rating: +3 (from 5 votes)

Riesgos: Debug con modificación de variables

Wednesday, March 11th, 2009

Empezamos con un tipo de post nuevo, donde vamos a ir enumerando entrada tras entrada diversos tipos de riesgos a los que podemos estar expuestos en la plataforma SAP y cuando sea posible las formas conocidas de minimiarlos.

En este primer caso vamos a enumerar uno de los más graves que puede ocurrir, y es el que el existan usuarios que en el ambiente productivo posean permisos para realizar debug o depuración, y a su vez el permiso de modificar el valor de las variables (y en las versiones más nuevas como ECC 6.0, ir a una línea de ejecución específica).

¿Qué es el DEBUG?

El debug o depuración es la capacidad de recorrer línea por línea el código fuente ABAP de la transacción que se ejecuta, en el caso de poseer el permiso en la actividad 02, uno puede a su vez modificar los valores de las variables de los programas.

El riesgo de poseer estos permisos es que prácticamente el usuario que lo ejecute puede saltearse todos los controles de autorización, ya que en el momento de  ejecutar una transacción, podría ir paso a paso por el código y cuando sus permisos no le permitieran seguir tras un AUTHORITY-CHECK fallido el podría cambiar ese valor de error, autorizándose a si mismo a continuar.

Un usuario con los permisos adecuado puede acceder al modo debug utilizando en la barra de acceso rápido de SAP el código “/h”.

Este modo de ejecución se permite cuando el usuario posee entre sus roles el permiso al objeto de autorización S_DEVELOP, el cual entre sus campos tiene el valor de ACTVT en 02 (modificar) y el valor de OBJTYPE en “DEBUG“.

Si se da esta condición (sin importar los valores de otros campos, pueden incluso estar vacíos), el usuario puede acceder al modo debug y modificar el valor de las variables.

La manera de evitar este inconveniente es justamente no brindando estos permisos en un ambiente productivo, salvo en un caso excepcional por tiempo limitado y a un usuario específico y nomenclado, para solucionar un error importante en el sistema.

Incluso este tipo de permisos no debiera otorgarse en los ambientes de desarrollo (modificar, el DEBUG común puede realizarse) , ya que también permite vulnerar la seguridad de los mismos y por consiguiente el entorno productivo podría llegar a verse afectado.

Para realizar la búsqueda de quienes tienen permisos para realizar esta acción lo ideal es utilizar la transacción SUIM y buscar los usuarios que posean este objeto de autorización y estos valores de campo.

En un próximo post vamos a hacer una explicación integral del uso de la transacción SUIM (probablemente en más de un post por lo extenso del tema)

VN:F [1.9.18_1163]
Rating: 4.8/5 (4 votes cast)
VN:F [1.9.18_1163]
Rating: 0 (from 0 votes)

Parámetros: Mejores prácticas (parte II)

Tuesday, March 10th, 2009

Siguiendo con el post del día de ayer nos quedaron algunos parámetros para seguir con las recomendaciones de “las mejores prácticas”:

Multiloguin

login/disable_multi_gui_login = Debe estar configurado en uno (1) para minimizar dos riesgos. Primero, que los usuarios no compartan su Id y su contraseña de manera que no sea identificable el responsable de las acciones, y segundo que no pueda loguearse concurrentemente un usuario que obtuvo una contraseña de otro, si el primero ya estaba logueado al sistema (quedando registrado el intento de loguin)

login/multi_login_users = Bajo este parámetro pueden definirse excepciones al caso anterior, pero lo ideal es no hacerlo salvo necesidad explícita y justificada.

login/failed_user_auto_unlock = Esto debe ser (0) para evitar que los usuarios bloqueados se habiliten automáticamente. Como mecanismo de control es importante la participación y control por parte del administrador para desbloquearlo.

login/fails_to_session_end = Si bien no es una medida de seguridad en si misma, permite molestar en los intentos de adivinar una contraseña. Lo ideal sería definirlo al menos en un número menos al valor de login/fails_to_user_lock

login/fails_to_user_lock = Para evitar los multiples intentos de adivinar una contraseña lo ideal es definir este parámetro en (3).

Otros parámetros

login/disable_cpic = Si no son necesarias este tipo de conexiones lo ideal es deshabilitar este tipo de acceso. (1)

login/no_automatic_user_sapstar = Lo ideal es deshabilitarlo (1) deshabilita). Para más información ver el artículo:  http://www.seguridadsap.com/sap/usuarios-por-defecto-sap-ddic-earlywatch-etc/.

rdisp/gui_auto_logout = Es interesante definir este parámetro por cuestiones de performance (sesiones activas) y para evitar que las estaciones de trabajo queden logueadas en ausencia del usuario (en conjunto con las políticas locales de las estaciones). Un valor lógico sería  20 minutos (1200)

login/system_client = Preferentemente podría dejarse que el usuario tenga que especificar el número de mandante como una medida adicional de seguridad para los intentos casuales de acceso.

La lista no trata de ser exhaustiva, y tiene fines didácticos e incluso está abierta a la discusión por parte de ustedes si así lo desean en los comments.

VN:F [1.9.18_1163]
Rating: 3.5/5 (2 votes cast)
VN:F [1.9.18_1163]
Rating: +3 (from 3 votes)

Parámetros: Mejores prácticas (parte I)

Monday, March 9th, 2009

En un post anterior repasamos el significado de muchos de los parámetros de usuarios vinculados con la seguridad del sistema, ahora vamos a ver cuales son algunos de los valores de los parámetros de SAP que equilibran las posibilidades de uso con la seguridad del sistema, y que muchas veces son requeridos por auditoría de sistemas en sus revisiones sobre el sistema.

Parámetros de restricción a las contraseñas:

login/min_password_lng = Es un parámetro que va a depender mucho de las políticas organizacionales definidas en su empresa, pero puede sugerirse que un valor de 8 es un buen equilibrio entre dificultad de la contraseña y la facilidad del usuario para recordarla.

login/min_password_lowercase = Es recomendable que se exija que al menos un caracter (1) sea en minúsculas, para aumentar la complejidad de la misma

login/min_password_uppercase = idem al anterior, deben estar definidos en conjunto determinando que al menos exista un caracter en minúsculas y al menos uno (1) en maýúsculas para asegurar la complejidad.

login/min_password_specials = Cantidad mínima de caracteres especiales (no 0 a 9, tampoco A-Z, ni a-z)

login/min_password_letters = Similar al caso anterior por lo que es de sugerir que al menos un caracter sea requerido para evitar las contraseñas solo numéricas.

login/min_password_digits = Similar al anterior al menos un (1)caracter debiera ser numérico.

login/min_password_diff = Es de sugerir que se configure este parámetro pero no de manera muy restrictiva porque evitaría que se puedan elaborar nuevas contraseñas. Lo ideal sería definirlo en dos (2) o (1) para evitar las famosas series numéricas progresivas.

login/password_history_size = Aquí es importante definir un número no demasiado alto porque los usuarios van a olvidarse facilmente sus contraseñas. Uno debe luchar entre hacer seguro un sisetma y no pasarse con estas definiciones ya que los usuario terminaran anotando sus contraseñas demasiado innovadoras! Lo ideal sería determinar un número como cinco (5)

login/password_expiration_time = Lo ideal es que la contraseña caduque cada 30 días.

login/password_change_waittime = Lo ideal es definir este valor en al menos un (1) día para evitar que los usuarios fuerzen el cambio de sus contraseñas.

login/password_max_idle_initial = Es importante definirlo evitar que contraseñas queden habilitadas por tiempo indefinido. Es utilizado para evitar que los usuarios sean dados de alta con contraseñas iniciales pero nunca ingresen al sistema dejando una puerta semi-abierta en el mismo sistema (contraseñas iniciales débiles). Debería ser en el orden de los 3 a 7 días.

login/password_compliance_with_current_policy = Este parámetro determina que durante los nuevos logins se verifique si la contraseña cumple con el estándar actualmente definido. (o no chequea, 1 chequea) De esta manera las modificaciones de parámetros de seguridad impactarán inmediatamente en los usuarios requiriendo que los mismos realicen un cambio de contraseñas en su próximo loguin si no cumplen la política actual.

Es importante recordar que el parámetro login/password_compliance_with_current_policy es el que va a definir si se va a requerir un cambio de contraseña masivo a las que no cumplan con las definiciones establecidas o se va a esperar a la próxima definición de las mismas. Hay que tener cuidado con este parámetro si se ha definido una política inválida y no puede establecerse una contraseña que cumpla con todos los requisitos ya que no nos dejaría ingresar más al sistema por las vías normales.

En el próximo post seguimos con los parámetros no vinculados a contraseñas que faltan.

VN:F [1.9.18_1163]
Rating: 4.0/5 (1 vote cast)
VN:F [1.9.18_1163]
Rating: 0 (from 0 votes)