Posts Tagged ‘SAP’

Parámetros de configuración de Seguridad

Thursday, February 19th, 2009

¿Qué son los parámetros de seguridad en SAP R/3? Es la manera que nos provee el sistema para determinar diferentes configuraciones del mismo ya sea de funcionamiento o performance (BASIS), como de seguridad… y estás últimas son las que más nos interesan.

A través de los mismos podremos definir cosas como el largo de la contraseña, la cantidad de dígitos obligatorios, tiempo de caducidad, entre otras opciones. La configuración de los mismos se hace a través de las transacciones RZ10 y RZ11 (perfiles globales, de instancia, o modificación dinámica).

En este post estaremos identificando siempre los parámetros con las versiones más actualizadas de SAP a la fecha… es posible que en versiones anteriores a SAP ECC 5 no se encuentren todos los aquí enunciados o tengan modificaciones en sus valores posibles.

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

login/min_password_lng = El cual permite definir el tamaño mínimo de la contraseña que va desde 3 a 40 (en las versiones más nuevas de SAP, anteriormente solamente hasta 8 )

login/min_password_lowercase = Cantidad mínima de caracteres en mínusculas.

login/min_password_uppercase = Cantidad mínima de caracteres en mayúsculas.

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

login/min_password_letters = Cantidad mínima de caracterés del alfabeto en la contraseña.

login/min_password_digits = Cantidad mínima de dígitos obligatorios en la contraseña (0-9)

login/min_password_diff = Cantidad de caracteres que deben diferenciarse entre la nueva contraseña y la anterior (para cambios de contraseña realizados por el usuario)

login/password_history_size = Cantidad de contraseña guardadas como historial de manera que no puedan repetirse las últimas “n” contraseñas (Mínimo 1 y Máximo 100).

login/password_expiration_time = Cantidad de tiempo definida en días que transcurre antes que expiré la contraseña del usuario y el sistema solicite un cambio de la misma. (el valor mínimo es 0 que significa sin caducidad y 1000)

login/password_change_waittime = Cantidad de días que deben transcurrir antes que el usuario pueda cambiar por sus propios medios nuevamente una contraseña. (Es para impedir que se evite el control de historial de contraseñas cambiando numerosas veces una misma contraseña)

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.

login/password_max_idle_initial = Máximo número de días que la contraseña definida por el administrador (inicial) puede permanecer habilitada para que el usuario la utilice. (0 a 1000). 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)

login/password_max_idle_production = Similar al anterior pero aplicable a los cambios realizados por los mismos usuarios.

login/disable_password_logon = Permite desactivar el logueo por contraseña si se utiliza otro medio como ser SSO o SNC, para acceder al sistema.

login/password_logon_usergroup = Grupo de usuarios que podrá loguearse con contraseña a pesar de haber usado el parámetro login/disable_password_logon.

login/password_change_for_SSO = Define el comportamiento de la solicitud de cambio de contraseñas para sistemas con SSO (o a 3)

Estos son los parámetros de definición de las contraseñas que tiene SAP, en el próximo post vamos a incluir los respectivos a logueo de errores de logon, multilples loguins y otros varios.

VN:F [1.9.10_1130]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.10_1130]
Rating: +3 (from 3 votes)

Usuarios por defecto (SAP*, DDIC, EARLYWATCH, etc)

Wednesday, February 18th, 2009

Hoy vamos a hablar de los usuarios por defecto del sistema SAP. Habitualmente estos usuarios los podemos encontrar no solo en R/3 si no que, en principio, también están presentes en los otros sistemas (BW, PI, Solution Manager, etc)

Estos usuarios existen por diversos motivos, principalmente vinculados con el propio funcionamiento del sistema, la instalación o la configuración del mismo.

DDIC

Podemos encontrar en principio el usuario DDIC, el cual es el utilizado para la gestión del diccionario de datos, modificación de estructuras de datos, upgrades del sistema, etc. Por estos motivos el usuario no debe ser eliminado del sistema si no que por el contrario debe ser modificada su contraseña de origen la cual viene por defecto definida como 19920607, ya que dejar este usuario con la contraseño por defecto nos expondría a riesgos asociados con los permisos amplios del mismo para operar con el sistema.

EARLYWATCH

Este usuario si bien no posee permisos tan amplios como DDIC permite el acceso al sistema con una contraseña por defecto: SUPPORT. Este usuario es utilizado para el proceso de revisión periódica del sistema por parte de SAP, en donde revisa la performance del equipo de manera remota, las licencias, etc a través de un acceso por SAPRouter. Es recomendable cambiar la contraseña de este usuario en el mandante 066 (al que accede SAP para estas evaluaciones)

SAPCPIC

Usuario utilizado para los procesos de comunicación entre sistemas y el cual también posee permisos amplios, la política es similar a la del usuario DDIC y es de cambiar su contraseña por defecto ADMIN

SAP*

Un caso parecido a DDIC, y tal vez el más grave ocurre con el usuario SAP*, el cual es el usuario con el que por primera vez iniciaremos el sistema después de la instalación, y que posee amplios permisos sobre la aplicación. En versiones anteriores a las ECC 5 de SAP la contraseña por defecto era 06071992, pero a partir de la misma se pregunta durante la instalación la contraseña inicial. Este usuario tampoco debe ser eliminado ya que es de utilidad en determinadas ocasiones para aplicaciones de parches, updates, upgrades y algunas tareas en particular que lamentablemente tienen este usuario hardcodeado como el único que puede ejecutarlas.

Borrar el usuario SAP*

Las precauciones con el usuario SAP* deben extremarse ya que en caso de borrarse el usuario de sistema la aplicación tiene un BUG o mecanísmo de seguridad en donde se genera un nuevo usuario SAP* con contraseña por defecto PASS. De esta manera si borramos el usuario SAP* estaremos abriendo un agujero de seguridad aún más grande ya que no podría cambiarse la contraseña por defecto.

La solución a este problema viene dado por un parámetro seteable en la transacción RZ11 de nombre (login/no_automatic_user_sapstar) el cual para no permitir este agujero de seguridad debe estar definido con el valor 1. (Ver artículo sobre parámetros)

Preventivamente es recomendable bloquear al usuario SAP* y desbloquearlo solo en caso de necesidad explícita de uso.

Recomendaciones Finales:

Cualquier usuario creado por defecto por el sistema implica un riesgo, ya que a los mismos se les conocen habitualmente varias vulnerabilidades. Lo primordial: cambiar sus contraseñas por defecto y de ser posible bloquear los usuarios sin borrarlos (caso SAP*). Una buena forma de verificar preventivamente esto es ejecutar desde la transacción SA38 el report RSUSR003, el cual nos brindará la información sobre las contraseñas por defecto de estos usuarios.

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

La seguridad en SAP – Roles y permisos (ejemplo)

Tuesday, February 17th, 2009

En esta entrada vamos a ver un ejemplo de acceso a través de la transacción PFCG (Profile Generator) a un rol o papel, las posibilidades de modificación y su vínculo con perfiles de manera que todo lo que explicamos en las entradas anteriores quede un poco más claro.

1- Una vez logueados en SAP, ingresamos a la Transacción PFCG ingresando su nombre en la barra de ejecución rápida y presionando Enter (Intro) o haciendo click en el tilde verde de la izquierda

image

2- Una vez que ingresamos a la transacción podemos ver como nos muestra su interfaz de usuario a través de la cual si hacemos click en Vistas podemos elegir roles simples para ver en la lista de abajo los primeros doscientos con el criterio seleccionado como Filtro (si es que lo utilizamos)

image

image

3- Una vez que se muestra la lista buscamos el rol que queremos modificar o también podemos escribir directamente su nombre en el campo Rol o utilizar la alternativa de búsqueda del mismo campo a la izquierda (cuadrado gris).

4- Desde estas opciones se puede elegir modificar un rol existente (lápiz), visualizar sus datos (anteojos), crear un nuevo rol simple o uno compuesto.

image

5- Una vez en la pantalla siguiente a través de modificar podemos ver una nueva pantalla con datos de descripción, fecha de creación del rol, última modificación, datos de herencia y otras pestañas con el Menú, la solapa de autorizaciones, Usuarios que lo tienen asignado y dos más de menor utilidad práctica (o habitualidad).

image

6- En la solapa de menú podemos observar las transacciones asignadas al rol a través del menú y en este lugar es donde pueden sacarse o agregarse transacción de manera estándar. Este menú es que el usuario que tenga asignado este rol va a ver a la izquierda de su pantalla cuando ingrese a SAP (en conjunto con otros menús que pueda tener por otro roles)

image

7- En la solapa de autorizaciones se puede ver la información del perfil que utiliza SAP para asignar estas autorizaciones (su nombre empieza con T* siempre) y las opciones de modificar las autorizaciones existentes).

image

8- En la solapa de usuarios se pueden apreciar los usuario que tienen asignado el presente rol, pudiéndose asignar nuevos o eliminar asignaciones existentes. A cada asignación a usuario puede definírsele una fecha de inicio y otra de caducidad para la asignación del rol.

image

La idea de esta entrada era que se aprecie como se maneja un rol (papel o grupo de actividad) en SAP y en una próxima entrada estaremos viendo como ejemplo la creación o modificación de un rol y profundizando más en el tema.

VN:F [1.9.10_1130]
Rating: 5.0/5 (4 votes cast)
VN:F [1.9.10_1130]
Rating: +6 (from 6 votes)

Módulo MM SAP (Parte I)

Wednesday, February 4th, 2009

El módulo de SAPMaterials Management“, comúnmente llamado MM, administra y controla los materiales y servicios de la organización. Es decir, participa dentro del proceso de una organización desde que surge la necesitad de compra de un material / servicio hasta que el mismo es recibido / consumido, y finalmente facturado.

 

Como todo módulo dentro de SAP, MM tiene una estructura y datos maestros a definir antes de poder ejecutar transacciones…. pero que es un dato maestro? Cómo defino la estructura de la organización dentro de SAP?

 

Acá van las respuestas!

 

Un dato maestro es una entidad que puede ser utilizada en varios módulos de SAP, pero se encuentra almacenada en un único repositorio, buscando de esta manera evitar datos repetidos, unificar información y por ende poder guardar historiales permitiendo sacar métricas, resúmenes, etc

Un ejemplo de dato maestro es el listado de materiales de la compañía, ya que los mismos se agrupan en “el maestro de materiales”, el cual puede ser utilizado por el módulo MM seleccionando el material que se quiere adquirir, así como también por el módulo PM seleccionando el material que debo utilizar para arreglar una determinada máquina. Otros ejemplos de datos maestros son: los proveedores y clientes.

 

Dentro del módulo MM se manejan los siguientes datos maestros: Materiales, proveedores y registros info (almacena datos de compras teniendo en cuenta materiales, proveedores, planta/centro, etc)

 

Otro punto a tener en cuenta para trabajar dentro de SAP es la definición de la estructura, es decir la representación de la organización dentro del sistema. Dentro de dicha estructura hay que definir: de qué cliente estamos hablando, las compañías que son parte del cliente, y dentro de las compañías, cada planta/centro y almacén que son parte de la misma.

Esta es una breve introducción al módulo de SAP MM, el cual tiene bastante implicancias directas con el armado de la seguridad en SAP, las cual más adelante vamos a ver… como ser el armado de estrategias de liberación, roles por centro, almacen, organización de compras, etc.


VN:F [1.9.10_1130]
Rating: 4.8/5 (4 votes cast)
VN:F [1.9.10_1130]
Rating: +4 (from 4 votes)

Algunas Transacciones Importantes

Monday, February 2nd, 2009

Por ahora vamos a ir detallando algunas transacciones que pueden ser importantes para quien trabaje administrando o analizando la seguridad,  más adelante vamos a incorporar otras siguiendo algún criterio de criticidad de las mismas, pero por lo pronto:

SU01 = Sirve como ABM de Usuarios, desde este transacción se da el alta a nuevos usuarios, se los puede borrar definitivamente, se pueden modificar sus datos, bloquearlos, asignarles Roles, entre varias actividades más

SU01D = Igual a la anterior pero solo para visualización de datos de usuarios.

SU10 = Esta transacción sirve para hacer modificaciones en masa de usuarios, desde la misma pueden modificarse campos en los mismos, borrar un conjunto de roles o asignar en masa roles a usuarios. Hay que tener mucha precaución al trabajar con la misma por el impacto que puede ocasionar.

PFCG = Esta transacción sirve como ABM de Roles (Papeles o Grupos de Autorización), dentro de la misma se crean nuevos roles, se modifican existentes, o se los borra, también desde esta transacción con los permisos adecuados uno puede asignar estos roles a los usuarios. Al trabajar con roles hay que tener en cuenta que si erroneamente borramos uno NO HAY una papelera de reciclaje o similar.

SU02 = Modificación/Creación de Perfiles de Usuario. Si bien está cuasi-obsoleta todavía pueden crearse roles y asignar los mismos a los usuarios con lo cual sigue siendo importante.

SU1, SU2, SU3 =  Actualización de Datos propios del usuario (incluida la contraseña). Aquí el usuario puede modificar sus propios datos personales, en versiones anteriores de SAP (4.6 o 4.7) o en las más nuevas dependiendo como esté configurado el sistema si se da acceso libre a modificar su propia contraseña es posible que un usuario cambie más de una vez la suya en un mismo día para evitar tener que hacer una modificación por caducidad de la misma (precaución)

SUIM = Sistema de información de Usuarios. Esta transacción va a merecer no solo un post entero, si no que probablemente más de uno para explicarla en su totalidad. Pero básicamente podemos decir que es el lugar desde donde se pueden realizar consultas sobre los permisos de los usuarios con diferentes parámetros. Es de extrema utilidad para el usuario que revisa o analiza la seguridad de un sistema SAP.

SU53 = Permite ver el último error de autorización que tuvo el usuario en el ambiente SAP (u otro usuario que previamente hubiera ejecutado la SU53). Es de suma utilidad para el análisis de errores de seguridad y una herramienta muy conocido por los administradores de seguridad. Probablemente un post entero sea dedicado a la gestión de errores de autorización.

Estas son algunas transacciones básicas… más adelante seguiremos viendo algunas otras.

VN:F [1.9.10_1130]
Rating: 4.0/5 (2 votes cast)
VN:F [1.9.10_1130]
Rating: 0 (from 2 votes)

SAP_ALL o Permisos Amplios

Friday, January 30th, 2009

El perfil SAP_ALL, es un permiso del cual, si trabajamos con SAP lo vamos a escuchar nombrar innumerables veces, y más de una vez puede producir que abramos los ojos en sobremanera! ;-)

Este permiso básicamente consta de todas autorizaciones posibles en SAP ECC (Enterprise Central Components) con lo cual quien tenga este perfil asignado a su usuario va a poder realizar cualquier actividad sobre el sistema.

El perfil es un perfil compuesto (por el número de autorizaciones que tiene no puede ser un perfil simple), el cual otorga acceso a todas las transacciones del sistema y posee valores amplios (*) en todos los objetos de autorización estándar.

La problemática oculta tras este perfil es que muchas veces vamos a escuchar que es indispensable para realizar tareas de administración del sistema, entre otras cosas.

Esto NO es así, si bien escasos (muy escasos) procesos deben obligatoriamente ejecutarse con permisos sumamente amplios… más veces el requerimiento obligatorio es del usuario SAP*, que del perfil SAP_ALL. Con lo cual este solo debiera ser incorporado en el proceso de cambios de emergencia de ser necesario, y no como un permiso habitual asignado a los usuarios de administración (o cualquier otro).

¿Usted confiaría en un Jr de Sistemas para que tenga todos los permisos en el sistema? ¿para que apruebe las ordenes de compra? ¿Para que las haga? ¿Para que ejecute pagos?

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

Perfiles de autorización

Thursday, January 29th, 2009

En un post anterior explicamos lo que era un Rol o Grupo de Autorizaciones, bueno ahora vamos a tratar de explicar que es un Perfil (o Perfil de autorizaciones).

Antiguamente la seguridad de SAP era un poco más rudimentaria que la actual, era manejada mediante Perfiles de Autorización. Los perfiles no tienen una diferencia sustancial conceptual con lo que es un Rol, simplemente las herramientas para trabajar con ellos eran más límitadas (transacciones SU02, SU03).

Básicamente un perfil era un conjunto de autorizaciones, y el pérfil se le asignaba directamente a un usuario.

Ahora porque explicar que es un perfil si lo relatamos en pasado, como algo que ya no existe… porque esto no es tan así… Al margen de las instalaciones más viejas de SAP (4.0 y anteriores), en las versiones actuales SAP trabaja con perfiles por debajo de los roles.

¿Qué quiere decir eso? Que lo que vemos como roles es simplemente una capa superior a la capa de perfiles que está debajo solo que con la complejidad del manejo de perfiles simplificada porque lo hace SAP automáticamente.

Basicamente por cada rol creado pueden existir uno o más perfiles creados automáticamente por SAP que van a ser los que efectivamente nos den las autorizaciones.

Por eso si ustedes van a ver las autorizaciones específicas van a encontrarse que tienen una pestaña de Roles y otra de Perfiles (que su nombre empieza con la letra T y no pueden ser modificados manualmente) a través de los cuales tienen los permisos asignados.

Hasta ahora es bastante anécdótico el motivo por el que explico los pérfiles, pero hay un motivo más profundo, todavía pueden crearse perfiles manualmente y asignarselos a un usuario, o utilizar un perfil creado anteriormente de la misma manera.

Y adicionalmente… existen perfiles que vienen en la instalación de SAP que pueden ser asignados a los usuarios finales y que muchas veces contienen permisos sumamente amplios, como es el caso del famoso perfil SAP_ALL.

El caso específico del perfil SAP_ALL podemos tratarlo en un post separado pero básicamente podemos decir que nos brinda un acceso irrestricto al sistema a través de sus permisos.

Aprovechando la introducción del perfil SAP_ALL puedo contarles que existen a su vez perfiles simples y perfiles compuestos, siendo la diferencia que los segundos son perfiles de perfiles, o perfiles que solamente contienen otros perfiles dentro (con sus consiguientes autorizaciones)

Resumiendo este post… Existen perfiles que son creados automáticamente por SAP (T-*), existen otros que ya vienen con el sistema y poseen autorizaciones sumamente amplias (SAP_ALL), y a su vez los perfiles pueden contener dentro de si otros perfiles (perfiles compuestos).

Uno de los riesgos a tener en cuenta es que por como está dispuesta la pantalla donde uno consulta los usuarios (una pestaña de roles y otra de perfiles) uno puede llegar a confundirse pensando que un usuario no tiene ninguna autorización crítica mirando el contenido de la pestaña de roles, cuando en realidad si uno revisara la pestaña de perfiles uno podría ver que adicionalmente tiene asignado por ejemplo, los permisos de SAP_ALL.

Un error común, algunos pueden llamarlo tonto, pero sepan que puede pasar. Igualmente más adelante vamos a ver maneras más prácticas de revisar los permisos que efectivamente tiene un usuario.

Ejemplo de uso de la PFCG y vínculo de roles y perfiles

VN:F [1.9.10_1130]
Rating: 5.0/5 (2 votes cast)
VN:F [1.9.10_1130]
Rating: 0 (from 0 votes)