Posts Tagged ‘SAP’

Auditar SAP – Revisión (II)

Friday, November 6th, 2009

Continuando con los pasos que se habían detallado previamente, seguimos con los puntos a verificar en una auditoría:

6- Verificar que los permisos para trabajar con órdenes de transporte, tareas, y pasajes entre ambientes, estén asignados a las personas que deben cumplir los respectivos roles y que se cumpla la segregación de funciones. Verificar el objeto S_TRANSPRT, y los permisos a las transacciones SE09, SE10, STMS, etc (Ver este link sobre el sistema de transporte, y detalles sobre los objetos de autorización en este link)

7- Verificar que los programas Z (customizados) posean los authority check que requiramos. Esta búsqueda se puede realizar facilmente a través del programa RSABAPSC ejecutado desde la transacción SA38.

8- Revisar los parámetros definidos en el perfil de instancia (a través del reporte RSPARAM (SA38), o la transacción RZ11. (Más info)

9- Verificar todos los usuarios que posean permisos para desarrollar en ambientes productivos (Objeto S_DEVELOP con actividades 01, 02 o 06), y que también dispongan de la transacción SE38

10- Verificar que los permisos de debug con modificación de variables no estén asignados en un ambiente productivo (S_DEVELOP, actividade 02 y tipo de objeto DEBUG) (Más info…)

11- Ejecución de Querys, verificarlo revisando qué usuarios pueden ejecutar la transacción SQ01 y el objeto S_QUERY con 02 o 23.

En un próximo post seguiremos profundizando con el programa de auditoría que venimos elaborando en este blog.

VN:F [1.8.2_1042]
Rating: 5.0/5 (4 votes cast)
VN:F [1.8.2_1042]
Rating: +4 (from 4 votes)

Auditar SAP – Revisión (I)

Wednesday, September 23rd, 2009

En el presente gráfico podemos observar la pirámide de una auditoría completa, pero identificando que en este primer esquema nos vamos a concentrar en la auditoría del Sistema Basis de SAP

image

Recuerden que los primeros pasos a seguir los detallamos en el primer post, y en el presente ya ahondaremos en los primeros controles técnicos a realizar.

1- Verificar el acceso al customizing, específicamente a la transacción SPRO por parte de los usuarios y los permisos del objeto S_IMG_ACTV. Lo ideal es restringir estos permisos a los usuarios en general y solo usuarios de emergencia o funcionales puedan visualizar (03) el customizing en pos de la solución de problemas de desarrollo. Adicionalmente podrían verificarse que no existan permisos innecesarios directamente a muchas de las transacciones del customizing (O*).

Este control es independiente de los permisos definidos para el mandante en general mediante la transacción SCC4, ya que se busca restringir los permisos a fin de evitar que un mandante abierto por error pueda ser modificado, y como siempre también, evitar el otorgamiento de permisos innecesarios.

2- Restringir el acceso a la transacción SCC4 para evitar la gestión del mandante por usuarios no autorizados.

3- Verificar en la transacción SCC4 la configuración del mandante, de forma de no permitir cambios en un mandante productivo, así como tampoco debería permitirse la ejecución de CAATs o eCAATs, ni sobrescribir el mandante (S_TABU_DIS ACTVT=2, Group=SS; S_ADMI_FCD=T000; S_TABU_CLI=X) (Más info)

4- Revisar los permisos otorgados mediante S_TABU_DIS a los usuarios (permisos de modificación directa de tablas) evitando otorgar cualquier permiso a todas las tablas o tablas del sistema (* o SS, entre otros), controlar los permisos a las tablas Z* y que las mismas tengan grupos de autorización vinculados. Verificar en conjunto con el acceso a las transacciones SE16, SE16N, SE17, SM30, SM31 y variantes. (Más info)

5- Verificar la posibilidad de ejecutar programas directamente por parte de usuarios finales (acceso a transacciones SA38, SE38, SE80, SE37), en conjunto con el objeto S_PROGRAM, y la existencia de programas sin grupo de autorización (tabla TRDIR campo SECU). (Más info)

Esto es solo un comienzo de una serie de artículos que detallarán un plan de auditoría y los pasos a seguir. Cualquier sugerencia es bienvenida.

VN:F [1.8.2_1042]
Rating: 4.9/5 (7 votes cast)
VN:F [1.8.2_1042]
Rating: +3 (from 3 votes)

Auditar SAP – Introducción

Thursday, July 30th, 2009

A lo largo de varios post en este blog vimos desde artículos introductorios, hasta algunas pequeñas herramientas que SAP nos brinda para ayudarnos a configurar su seguridad.

En este post, y los subsiguientes sobre “Auditar SAP“, trataremos de abarcar paso a paso, las tareas a realizar para evaluar la seguridad de un sistema. En algunos casos repitiéndo conceptos ya definidos en anteriores artículos del blog, e incorporando otros nuevos.

Lo principal a fines de empezar, es entender el alcance de la auditoría que vamos a realizar. Metodológicamente, una auditoría del sistema se concentra en revisar la configuración del mismo, con el fin de exponer las falencias que puedan poner en jaque la seguridad de la información que en el reside.

Tenemos que comenzar entendiendo que el sistema SAP como ERP, es un sistema que puede aportar un alto grado de seguridad en las operaciones, y posee un buen número de controles embebidos en el mismo, tanto configurables como inherentes. Pero esta seguridad tiene que ser configurada, para que sea efectiva.

Y también es importante destacar una característica particular de SAP a la hora de auditarlo, y es que en el mismo no solo se configuran y por consiguiente, se revisan, los controles de aplicación (controles internos del negocio, validaciones de datos, etc) si no que también un gran número de controles de base o generales deben efectuarse en el mismo, ya que desde dentro de un sistema SAP es posible acceder directamente a las tablas de base de datos, ejecutar programas, ver código fuente, ejecutar comandos de sistema operativo, apagar el servicio, realizar debugging, y un largo etc de actividades que en otros sistemas deben controlarse “por fuera de la aplicación” y en el caso de SAP deben controlarse en “ambos lugares”. Y resaltamos “ambos lugares” porque incluso en muchas revisiones de seguridad se pierde el foco y se controlan los permisos dentro del sistema con el fin de verificar controles generales y de aplicación, abandonando un poco el control sobre los servidores de base de datos, de aplicación, etc.

Igualmente como corresponde a este blog, nos ocuparemos, al menos en principio, a la revisión de la seguridad específica en la plataforma SAP y posteriormente incorporaremos tips a verificar en las plataformas subyacentes (pero es tan variado este control, como plataformas y bases de datos sobre las que puede instalarse SAP).

Antes de empezar efectivamente con la auditoría sobre el sistema, hay cierta información que uno debería recopilar, y vamos a explicar porque:

- Versión, o versiones de SAP sobre la que se va a trabajar - Distintos parámetros y configuraciones son posibles dependiendo de la versión del sistema, como así también nuestras recomendaciones varí an según la versión de SAP, salvo que nuestra recomendación se actualizar la versión ;-)

- Cualquier informa de auditoría previo – Nos puede dar una idea general del sistema, aunque la revisión deba hacerse de cero.

- Landscape, número y nombre de instancias - Por motivos obvios es necesario conocer el landscape sobre el que se trabaja, servidores involucrados, application servers lógicos, físicos, ambientes de desarrollo, pruebas, producción etc. Es importante que los ambientes se encuentren correctamente aislados el uno del otro.

- Sistema operativo y Base de Datos (Nombre, versiones, etc) – Averiguar el sistema operativo sobre el que está instalado el application server y la base de datos sobre la que corre es importante tanto para  la revisión de software de base, como para algunas transacciones específicas del sistema según donde se instale.

- Mandantes - Conocer los mandantes existentes y el objetivo de los mismos es necesario por las mismas razones que las instancias, y para conocer las necesidades de auditoría.

- Cantidad de usuarios - Complejidad y extensión de la revisión.

- Módulos utilizados/implementados - Para conocer el alcance de la revisión, una aproximación del número de roles involucrados y complejidad, la cual puede depender de los módulos (sobre todo si son incluidos módulos de industria específicos que si bien pueden no agregar muchos controles de seguridad, pueden ser desconocidos para nosotros)

- Esquema general de Sociedades, Centros, Sociedades CO, y otros datos funcionales - Resultan útiles a la hora de evaluar un esquema de roles acorde a las necesidades de la organización.

- Número de desarrollos ABAP o Z - Nos servirá como dato sobre la complejidad del sistema y de su diferencia con el sistema estándar. Este dato es de suma importancia a la hora de saber lo complejo del análisis de roles y en un posible caso de reingeniería de los mismos.

- Toda la documentación del área de sistema definiendo procedimientos, misiones y funciones, organigrama, nómina de empleados del área de sistemas con funciones, monitoreo, etc - Es útil con el fin de confirmar que estos procedimientos y puestos se vean reflejados en la estructura del sistema, y que los permisos de usuarios en el sistema no excedan o limiten sus responsabilidades. Es importante conocer el procedo de gestión de usuarios y accesos, para ver que el mismo se refleje de manera adecuada en el sistema.

- Procedimiento de cambios, y cambios de emergencia Es importante contar con este procedimiento escrito y de no ser así relevar el proceso que debería ser, para comprobar que el sistema de transporte y los permisos estén configurados de manera acorde.

- Procedimiento de ABM de Usuarios y rolesEs de suma importancia conocer el procedimiento para poder contrastar la realidad del sistema con tra lo teóricamente definido, y si lo teóricamente definido es correcto o adecuado.

- Usuarios de Interfaz o no nomenclados - Es importante conocer de antemano cuales son estos usuarios para verificar su correcta parametrización o recomendar su eliminación.

- Esquema de Nomenclatura de roles - Como son nomenclados los roles es vital para entender la estructura de los mismos.

- Nomenclatura de usuarios - Para verificar que se cumpla y comprender la misma.

- Metodología de Acceso al sistema - A través del SAP GUI, Web, interfaz desde otras aplicaciones, usuarios de internet, externos, SAP Router, Citrix. Es importante determinarlo con el fin de verificar el alcance y saber con que estamos tratando.

- Implementación de Seguridad a través de la estructura organizativa, o la utilización de perfiles estructurales - Cambio nuestro punto de vista sobre como revisar la seguridad del sistema.

- Topología de Red del sistema SAP - Realizar un análisis preliminar de la instalación y su seguridad

- Planes de continuidad del sistema - Además de lo obvio, para conocer la redundancia, el riesgo y otros sistema que debamos verificar.

- Existencia de permisos de visualización para auditar el sistema - Lo dejamos para el final, pero es de suma importancia poseer permisos a todo lo que necesitemos, pero sin modificación, para poder trabajar con tranquilidad sobre el sistema. Ya que de ser negado el acceso interactivo al sistema tendremos que encarar una auditoría COMPLETAMENTE DISTINTA.

Evidentemente todavía no abordamos nada técnico, pero es un paso esencial el de recopilar toda la información que sea posible. Si a ustedes se les ocurre alguna otra información específica a recopilar no duden en hacer comentarios en este artículo.

En el próximo abordaremos ya más en detalle los temas técnicos y cómo proseguimos con una auditoría del sistema.

Continúa aquí…

VN:F [1.8.2_1042]
Rating: 5.0/5 (3 votes cast)
VN:F [1.8.2_1042]
Rating: +8 (from 8 votes)

Novedades: Más canales de comunicación

Monday, July 20th, 2009

Después de una semana de merecidas vacaciones prometo volver en breve a la actividad en el blog, mientras tanto les dejo un nuevo canal de comunicación (twitter) en donde además de realizar avisos sobre nuevas publicaciones, incorporaremos material adicional al publicado en este blog.

Dado el formato de comunicación más conciso que twitter plantea, la idea principal es que mediante este canal se publiquen facilmente documentos interesantes, links a otros sitios con información de SAP, o toda información que no amerite la publicación de un nuevo post pero que pueda ser util para la comunidad.

La dirección del profile es http://twitter.com/seguridadsap desde donde pueden seguirnos y recibir las actualizaciones. En breve procuraré incorporar la funcionalidad de suscripción en el diseño de blog.

Saludos!

http://twitter.com/seguridadsap
VN:F [1.8.2_1042]
Rating: 0.0/5 (0 votes cast)
VN:F [1.8.2_1042]
Rating: +1 (from 1 vote)

AIS – Sistema de Información de Auditoría

Wednesday, July 8th, 2009

Las necesidades organizacionales muchas veces llevan a que se efectuen auditorías sobre los sistemas que las empresas tienen en pos de cumplir con requerimientos tanto internos, como externos.

SAP es una herramienta desarrolalda para las grandes corporaciones, y por ello es que dispone de facilidades para realizar auditorías sobre el mismo, que no es lo mismo que decir que es fácil realizar una auditoría de SAP.

En el presente post vamos a hacer un breve resumen del Sistema de Información de Auditoría (AIS), las posiblidades que nos brinda y como utilizarlo.

En las versiones más viejas de SAP, existía una transacción llamada SECR, a través de la cual se accedía a los distintos reportes. Por cuestiones de compatibilidad en las versiones más nuevas se mantiene, aunque está obsoleta.

El AIS de las nuevas versiones (posteriores a la 4.6c) está conformado por un conjunto de roles, los cuales habilitan a realizar distintas actividades en el sistema. Mediante la generación y posteriores asignación de los mismos a los usuarios finales, se otorgan permisos para realizar diferentes reportes y queries sobre el sistema.

Cuando estos roles son asignados a un usuario el mismo dispone de un menú de árbol especial, donde tiene numerosos reportes y acceso a transacciones que pueden brindar información útil para realizar una auditoría.

Los roles que forman parte del AIS son todos los que poseen la siguiente estructura de nombre “SAP*AUDITOR*“, existen numerosos roles simples y también dos compuestos que integran varios otros, SAP_AUDITOR (auditor general) y SAP_AUDITOR_TAX (auditor de impuestos).

El rol SAP_AUDITOR está pensado para una auditoría general de controles y datos en el sistema, en cambio el SAP_AUDITOR_TAX como su nombre lo indica está mayormente enfocado al auditor de impuestos (accesos a la contabilidad en su mayoría)

Estos roles simples también tienen unas características particulares. Existen los roles como SAP_CA_AUDITOR_SYSTEM el cual no contiene menú alguno, solo objetos de autorización que nos brindan permisos tanto de visualización como de modificación en algunas transacciones. A su vez, también encontramos el SAP_CA_AUDITOR_SYSTEM_DISPLAY, el cual solamente permite la visualización de datos, y es más adecuado para un auditor en muchas situaciones.

Estos roles como dijimos no contienen menú alguno, y el menú está dado por otros roles, que no tienen autorizaciones, solo el menú:

SAP_AUDITOR_SA_BC (AIS – Sistema auditoría)
SAP_AUDITOR_SA_BC_CCM_USR   AIS (Sist.auditoría – Usuarios y autorizaciones)
SAP_AUDITOR_SA_BC_CUS_TOL   AIS (Sist.auditoría – Repository / Tablas)

Esta flexibilidad que nos brinda SAP, permite justamente combinarlos para otorgar con el mismo menú, permisos de visualización o modificación.

Siempre debemos respetar la idea global, de no trabajar con los roles estándar si no realizar copias “Z” de los mismos para evitar inconvenientes en upgrade o posibles parches.

En un próximo post profundizaremos en las posibilidades de reporting que nos brindan los roles de AIS, y como encarar una auditoría a través del uso del rol.

VN:F [1.8.2_1042]
Rating: 4.3/5 (4 votes cast)
VN:F [1.8.2_1042]
Rating: 0 (from 0 votes)

Seguridad de las impresiones

Wednesday, June 10th, 2009

Muchas veces la seguridad de un sistema SAP, está enfocada en prevenir la ejecución de determinadas actividades sobre el sistema. Restringir quien y cómo puede interactuar con el mismo.

Ese es un primer paso, cuando nace la preocupación por la seguridad y el control interno. Después de esto, es común que la preocupación recaiga en quien tiene la posibilidad de ver la información que está en el sistema. No solo nos importará quien puede ejecutar acciones, si no también nos importará quien puede visualizar los pagos realizados por la empresa, los proveedores, los sueldos, los clientes, y un largo etc de información que en sistema como SAP es almacenada, y que tiene VALOR para la organización.

En el presente post vamos a ver un factor, que muchas veces es despreciado, y que tiene potencialmente mucha importancia. La gestión del spool de impresión.

Muchas  veces se toman recaudas específicos, bajados desde la alta cúpula de la organización para que determinada información no sea visible “por todos” o por “cualquiera” y sin embargo quedan agujeros por donde esta puede ser consultada. Muchas veces es el acceso directo a tablas, el acceso directo a programas, la posibilidad de hacer queries, etc.

Pero la que hoy nos importa es: “La posibilidad de ver lo que otros usuarios mandaron a imprimir”.

Esto está regulado por los objetos de SPOOL, principalmente S_SPO_ACT, el cual otorga permisos para el SPOOL de OTROS usuarios, si uno quiere visualizar el SPOOL propio, no necesita autorización especial a este objeto. Las transacciones desde donde se puede gestionar el SPOOL de impresión son la SP01 y SP02 (principalmente la primera que permite ver SPOOLs ajenos)

Ahora pueden garantizarse distintas acciones (DISP – Visualizar, PRNT – Imprimir, REPR – Reimprimir, DELE – Borrar, USER – Cambiar propietario, DOWN – Download) las cuales actuan sobre el objeto de autorización especificado (Campo SPOAUTH)

Una excepción en los valores de este campo es el valor __USER__, donde se da acceso a las acciones establecidas, para todas las órdenes de spool que no tengan un grupo de autorización definido. (El cual define cada usuario a la hora de imprimir, lo cual no garantiza la seguridad del mismo)

Adicionalmente a estas autorizaciones es necesario poseer el objeto S_ADMI_FCD con valores SP01 o SP0R, a través de los cuales podrá gestionar la salida de SPOOL con libertad.

Por todo lo que antes nombrabamos es importantisimo restringir estos permisos, ya que de no hacerlo estaríamos librando la visualización de cualquier documentación impresa desde el sistema SAP a cualquier usuario si es que el mismo no la restringe apropiadamente.

VN:F [1.8.2_1042]
Rating: 5.0/5 (3 votes cast)
VN:F [1.8.2_1042]
Rating: 0 (from 0 votes)

Tipos de Usuario en SAP

Thursday, May 7th, 2009

En todo sistema SAP tenemos 5 opciones para definir los tipos de usuario, con sus diferentes restricciones de acceso y condiciones a la hora de ingresar al sistema. Es importante establecer correctamente los tipos de usuario ya que no debería tener una configuración similar un usuario final, un usuario de interfaz, o uno de sistema, entre otras opciones.

Por eso pasamos a describir los 5 tipos de usuario distintos que podemos definir en SAP:

Usuarios de Diálogo – Dialog users (A)

Es el tipo de usuario con el que deben acceder normalmente los usuarios finales que necesitan interactuar con el sistema a través del SAP GUI. Todos los parámetros de logueo definidos son verificados al iniciar sesión, como así también las restricciones de loguins múltiples. Normalmente la mayoría de los usuarios de nuestra organización debieran estar encuadrados dentro de este tipo.

Usuarios de Sistema – System Users (B)

Los usuarios definidos bajo esta tipología son no interactivos, lo que significa que no pueden loguearse a través del SAP GUI al sistema. Comunmente son utilizados como usuarios de procesamiento por lotes, workflow, procesos ALE, etc. Su contraseña solo puede ser cambiada por el administrador del sistema y se permiten logueos múltiples. Uso interno dentro del mismo sistema.

Usuarios de Comunicación – Communication Users (C)

Utilizados para comunicación RFC entre sistemas, son los comunmente utilizados para las interfaces con otros sistemas. No es posible establecer logueos por parte de usuarios finales a través del SAP GUI.

Usuario de Servicio – Service User (S)

Es propicio para su utilización por parte de usuarios que requieren acceso anónimo. No respetan las normas de expiración de contraseña y la misma solo puede ser cambiada por el administrador del sistema. Las autorizaciones que se le otorguen al mismo deben ser mínimas y restringidas especificamente a la necesidad por la que se creo el usuario. Su uso no es recomendable salvo necesidad específica, ya que son logoneables mediante SAP GUI.

Usuario de Referencia – Reference User (L)

Este tipo de usuarios es poco utilizado en general. No admiten logons de diálogo y pueden ser utilizados para traspasar sus autorizaciones al usuario que lo tiene como referente.

Resumen

El esquema general de tipos de usuario es bastante simple, pero lo importante es aplicarlo correctamente restringiendo a los usuarios batch o de sistema para que no puedan tener logon directo al sistema, y a los usuarios de interfaz con su respectivo usuario de comunicación.

Esto es importante ya que muchas veces los permisos de estos usuarios son demasiado amplios (debieran restringirse, pero ese ya es otro tema), y sus contraseñas pueden estar comprometidas al tener que ser almacenadas en otros sistemas para su conexión.

VN:F [1.8.2_1042]
Rating: 3.7/5 (3 votes cast)
VN:F [1.8.2_1042]
Rating: 0 (from 0 votes)