hair grower


Posts Tagged ‘SAP’

Protección de Mandantes

Wednesday, May 6th, 2009

Un tema sumamente importante que solo fue tratado brevemente en este blog es el tema de la protección de los mandantes. Los disintos niveles de protección que SAP nos brinda para los mismos tienen una importancia mayúscula dentro del marco general de seguridad del sistema y gestión de ambientes.

Por ejemplo, dentro de los parámetros a definir se puede establecer que el mandante sea modificable, la posibilidad de copiar el mismo, realizar modificaciones independientes de mandante, etc.

Desde la transacción SCC4 podemos consultar y/o modificar la configuración de los mandantes, y dentro de las mismas se nos presentan varias opciones que es importante que nos queden claras y bien definidas.

1- Modificar objetos dependientes de mandante:

- Permitir libremente las modificaciones sin realizar órdenes de transporte automáticamente (No recomendado su uso, solo factible para ambientes Sandbox con rutas cerradas de transporte)
- Permitir modificaciones pero realizar automáticamente las órdenes de transporte respectivas (para reforzar la nivelación de ambientes hacia adelante, y la ejecución del proceso transporte, recomendable para ambientes de parametrización o customizing)
- No permitir modificaciones (o lo que se conoce como mandante cerrado, recomendable para ambientes productivos… y no solo recomendable… indispensable para mantener “cierto” control)
- Permitir las modificaciones de customizing pero anular las posibilidades de transporte incluso manuales (no recomendable, solo para entornos cerrados de pruebas)

2- Modificaciones de objetos independientes de mandante:

- Permitir todos los cambios (Recomendable para ambientes de desarrollo)
- Permitir solo cambios de Repository o workbench (Son solo modificables los programas, reportes, diccionario de datos, etc.)
- Permitir solo cambios de Customizing independiente de mandante (Solo el customizing y no el workbench)
- No permitir ningún cambio independiente de mandante (Ambientes de producción)

3- Protección contra copias de mandante:

- Sin restricciones
- Sin posibilidad de sobrescribir el mandante (habitual para la mayoría de los mandantes, salvo excepción puntual)
- Eliminar la posibilidad de tomarlo como origen de una copia de mandante (Es para evitar que un mandante que tiene información confidencial pueda ser copiado a otro mandante)

3- Protección contra uso de CATTS:

- Las herramientas de CATT o ECATT pueden ser utilizadas para realizar cargas masivas de datos en el sistema y por lo tanto se recomienda que se limite la posibilida de su uso en los ambientes productivos.

Es importante destacar que estas configuraciones son solo aproximaciones a lo que debería ser, y que sin embargo muchas veces ocurren excepciones a las reglas aquí definidas, ya que se habilitan temporalmente las posibilidades de copiar mandantes de producción para realizar pruebas (deberían anonimizarse sus datos), o copiar ambientes de desarrollo, etc.

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

Tips: Auditoría sin activar la auditoría

Friday, April 3rd, 2009

Estrenando un nuevo diseño en el blog creamos un artículo que puede llegar a ser útil aunque el título suene un tanto ambicioso. La realidad es que la idea básica es la de conocer si un usuario determinado ejecutó una transacción en SAP, o que usuarios ejecutaron una transacción (desde cualquiera de los dos puntos de vista).

La realidad es que la herramienta más idonea que podemos encontrar en SAP, es la transacción SM20N, y la veremos en profundidad en un futuro post.

Pero por ahora y en caso de una emergencia, y teniendo en cuenta que solo nos brinda información sobre acciones recientes, y no nos especifica la fecha y hora de esta ejecución (la cual puede aproximarse) vamos a ver como podemos ver esa información a través de la transacción ST03N.

Esta transacción nos permite evaluar la performance de ejecución en los distintos application servers, y su fin no es brindar información de seguridad, pero en determinados casos donde la auditoría no esté activada puede ser útil para nosotros.

En la misma seleccionando el Modo Experto, disponemos de un frame donde se encuentran las instancias de nuestro SAP. Una vez seleccionada una instancia en esta ventana, seleccionamos un período. Y vamos a la ventana que se encuentra inmediatamente abajo, seleccionando la vista Estadística de Usuario – Perfil de Usuario. Luego en la ventana principal vemos todos los usuarios con sus datos de performance, y si hacemos doble click en los mismos podemos ver que transacciones ejecutaron en el período de tiempo previamente seleccionado.

También existe la posiblidad de hacerlo a la inversa (desde la transacción los usuarios) a través de la vista “Perfil de Transacción”.

Es una alternativa interesante, si bien nunca debe ser la única, y el tiempo de la información resguardada va a depender de la configuración del sistema.

Es posible que nos resulte útil cuando se desea investigar de forma URGENTE, QUIEN EJECUTO tal transacción QUE ORIGINÓ TAL PROBLEMA, y nunca antes nos permitieron activar la auditoría por “cuestiones de performance” (o desconocimiento). Paradojicamente el Trace de performance nos puede brindar ALGO de esa información.

PD: Si necesitan algún capture de pantalla para hacerlo diganmé en los comments.

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

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: -1 (from 1 vote)

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: +5 (from 7 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)