INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELECTRICA

UNIDAD CULHUACAN

TESINA

Seminario de Titulación:
“Las tecnologías aplicadas en redes de computadoras”
DES/ ESME-CU 5092005/11/12

SEGURIDAD EN SAP

Que como prueba escrita de su

examen Profesional para obtener
el Título de: Ingeniero en
Comunicaciones y Electrónica

Presenta:
ISRAEL ROJAS LUNA

México D.F OCTUBRE 2012

 Agradecimientos

La presente Tesis es un esfuerzo en el cual, directa o indirectamente, participaron varias personas

leyendo, opinando, corrigiendo, teniéndome paciencia y dando ánimo.

Agradezco a mi esposa Adriana Gaona e hijas Renata y Regina por la oportunidad prestada para
concluir este gran esfuerzo sacrificando lo más importante en esta vida el tiempo de familia
dándome ánimos para final mente concluir este esfuerzo que iniciaron mis padres.

Igualmente a mis profesores de este seminario quienes me han orientado en todo momento en la
realización de este proyecto que enmarca el último escalón hacia un futuro en donde sea partícipe
en el mejoramiento día a día en mis actividades diarias.

I
 Índice

INTRODUCCIÓN .............................................................................................................................. 1
Generalidades de SAP ..................................................................................................................... 2
Estructura SAP ................................................................................................................................ 2
Transporte: ...................................................................................................................................... 3
CAPITULO UNO ............................................................................................................................... 4
Objetivo ........................................................................................................................................... 4
Ámbito de aplicación ...................................................................................................................... 4
Documentos relacionados ............................................................................................................... 4
Desarrollo ........................................................................................................................................ 4
Definición de Estrategia de Roles y Perfiles ............................................................................... 4
Definición de Roles Simples Maestros ....................................................................................... 5
Roles Compuestos ....................................................................................................................... 5
Segregación de Actividades ........................................................................................................ 5
Creación y Asignación ................................................................................................................ 6
Solicitud de Creación o Modificación de Rol ................................................................................. 6
Solicitud de Asignación .................................................................................................................. 6
Administración ............................................................................................................................ 7
Ciclo de Vida de roles ..................................................................................................................... 7
Creación y Modificación de Roles .............................................................................................. 7
Derivación de Roles .................................................................................................................... 7
Transporte de Roles ..................................................................................................................... 7
INTERACTUANDO CON EL SISTEMA ..................................................................................... 8
PFCG ............................................................................................................................................... 9
Nomenclatura de Roles ................................................................................................................. 10
Creacion de un Rol Simple............................................................................................................ 10
Pestaña Menú ................................................................................................................................ 12
Asignación de transacción – Modo estándar ................................................................................. 13
Asignación de transacción – Desde el menú de SAP .................................................................... 14
Asignación de transacción – Desde un Rol ................................................................................... 16

II
Asignación de transacción – Desde un archivo TXT .................................................................... 21
Pestaña de Autorizaciones............................................................................................................. 23
NIVELES ORGANIZACIONALES............................................................................................. 24
Metodología de manejo del proyecto ............................................................................................ 32
Evaluación ..................................................................................................................................... 32
PARTICIPACION ........................................................................................................................ 32
IMPLEMENTACION Y CREACION DE ROLES ...................................................................... 33
MATRIZ DE PRUEBAS .............................................................................................................. 34
ERRORES ..................................................................................................................................... 35
PLANEANDO LA INSTALACIÓN ............................................................................................ 37
Chequeando necesidades de Software y Hardware ................................................................... 37
Comprobando la red .................................................................................................................. 37
Distribución de los componentes en los discos ......................................................................... 37
Directorios creados durante la instalación................................................................................. 38
PREPARANDO LA INSTALACIÓN .......................................................................................... 38
CDs de Export ........................................................................................................................... 38
Instalando DLLs Actualizadas para el Sistema ......................................................................... 39
Memoria Virtual ........................................................................................................................ 39
Usuario y Permisos para la Instalación ..................................................................................... 39
Nombre del SAP System y del Servidor ................................................................................... 39
2.6 Preparando el directorio de Transportes .............................................................................. 39
INSTALACIÓN DEL SISTEMA SAP ......................................................................................... 40
Instalación del software de Oracle ............................................................................................ 41
Instalando R3SETUP ................................................................................................................ 42
Instalando SAP y cargando la Base de Datos............................................................................ 42
TRAS LA INSTALACIÓN .......................................................................................................... 45
Arranque y Parada del Sistema SAP ......................................................................................... 45
Entrando en el Sistema SAP...................................................................................................... 48
ANEXO I : Básico ........................................................................................................................ 49
ANEXO: CONFIGURACIÓN SEGÚN EL IMPLEMENTACIÓN ............................................. 50
Address Manteinance ................................................................................................................ 50
Perfiles de instancia y Modos de Operación ............................................................................. 51

III
 Sistema de Transportes.............................................................................................................. 53
Instalación de lenguajes ............................................................................................................ 54
Mantenimiento de tablas ........................................................................................................... 56
Cómo aumentar el tamaño de los tablespaces ........................................................................... 57
Import de los lenguajes ............................................................................................................. 57
Suplementación del Español ..................................................................................................... 60
Creación de los mandantes ........................................................................................................ 61
Creación del Sistema de Transportes del Implementación........................................................ 63
¿Qué ocurre si cambiamos el SID de la rz10?........................................................................... 65
Troubleshooting ............................................................................................................................ 65
Durante la Instalación................................................................................................................ 65
Alertas desde el SAP Management Console ............................................................................. 65
SAPGUI .................................................................................................................................... 66
ABAP Short Dumps .................................................................................................................. 66
Problemas importando lenguajes............................................................................................... 66
CAPITULO DOS .............................................................................................................................. 68
Objetivo ......................................................................................................................................... 68
ARQUITECTURA ............................................................................................................................ 68
COMO FUNCIONA LOS MANDANTES.................................................................................. 69
Mandantes ..................................................................................................................................... 69
SEGURIDAD EN MANDANTES ............................................................................................... 69
AMBIENTES ................................................................................................................................ 71
Ambiente de Calidad ................................................................................................................. 71
Ambiente de Producción ........................................................................................................... 71
Ambiente de Desarrollo ............................................................................................................ 71
EL SISTEMA DE TRANSPORTES SAP .................................................................................... 72
En resumen ................................................................................................................................ 73
ESQUEMA DE SEGURIDAD ......................................................................................................... 73
Seguridad en la aplicación SAP .................................................................................................... 75
MEJORES PRÁCTICAS .................................................................................................................. 75
Seguridad en las cuentas ........................................................................................................... 75
Seguridad en el Sistema de Archivos ........................................................................................ 75

IV
 Seguridad en los Servicios ........................................................................................................ 75
Seguridad en Bases.................................................................................................................... 75
La Problemática de la Seguridad de SAP...................................................................................... 76
Mecanismos de Autenticación ...................................................................................................... 76
Seguridad de los Usuarios ............................................................................................................. 76
Política de Contraseñas ................................................................................................................. 76
Mecanismos de Autorización ........................................................................................................ 76
Seguridad de las Interfaces ............................................................................................................ 76
POR QUE ANALIZAR LA SEGURIDAD DE SAP? ...................................................................... 77
Como Analizar la seguridad SAP.................................................................................................. 77
CONCLUSION ................................................................................................................................. 79
GLOSARIO....................................................................................................................................... 81
BIBLIOGRAFIA............................................................................................................................... 80

V
 Objetivos

El presente Trabajo nace con la intención de proporcionar una visión más sobre la aplicación de la
seguridad en la implementación de SAP en un Grupo Financiero. Desde el punto de vista
informático, basados en un estándar y cumpliendo las recomendaciones de distintas normas para
que en un futuro se logre la certificación deseada.

Siendo escasa la documentación sobre la implementación de la seguridad en SAP, este Trabajo se

presenta como un punto de partida para futuras implementaciones de este mismo sistema en
diferentes empresas.

Con este Trabajo también se pretende establecer principios básicos de Seguridad que sirvan de base
para la implementación de los nuevos sistemas y tecnologías para cumplir con los estándares
básicos.

Se ha realizado un análisis sobre la implementación realizada en Grupo Financiero Interacciones

con el objetivo de facilitar la configuración de la seguridad de la información con la creación de
roles y perfiles dentro del sistema SAP, permitan obtener el buen funcionamiento de los usuarios de
cada departamento.

Entre las necesidades básicas del análisis se hace especialmente relevante la de establecer un punto
de partida para la creación de roles y perfiles los procesos por cada área involucrada en la
implementación de cada modulo en SAP.

Finalmente se plantea el ambicioso objetivo de sentar las bases o el procedimiento que permita al
usuario entender lo importante que es la seguridad en cada uno de los procesos de finidos en la
implementación de este nuevo sistema.

VI
 Justificación

Este proyecto de tesis se enmarcara dentro de los parámetros y estándares de SAP así como las
buenas prácticas de la Seguridad de la información.

Académica
El presente proyecto representa la oportunidad de poner en práctica los conocimientos y experiencia
adquirida durante nuestra formación laboral como Oficial de Seguridad dentro del Grupo Financiero
en el cual labo actual mente dentro del área de sistemas de la información planteando una solución
viable y didáctica a una problemática de seguridad SAP en todas las empresas que adquieren un
sistema gestor de recursos ERP

Institucional
El proyecto de tesis tiene como finalidad poder brindar a cualquier empresa , el aseguramiento sus
procesos de negocio, teniendo como resultado una robustez en su política de seguridad de cada
empresa.

* Tecnológica
Este proyecto de tesis se justifica tecnológicamente porque contará con herramientas necesarias
que permitan identificar los puntos vulnerables en los procesos críticos de negocio, subprocesos,
actividades de control y requerimientos de las funcionalidades (de negocio y técnicas) que sirva
como soporte del rediseño de procesos y ayude a mejorar la calidad del servicio administrativo.
* Operativa
El desarrollo del presente proyecto implica un compromiso de todo el personal empleado de la
organización a fin de asumir un rol protagonista y luna nueva conciencia con la importancia de la
seguridad de la información asi como el compromiso a de nuevas responsabilidades en el desarrollo
de sus funciones como parte del rediseño de los nuevos roles dentro de la implementación de SAP
en el Grupo Financiero.
* Económica
La implementación del proyecto de tesis minimizara el impacto económico permitiendo obtener
ahorros significativos realizar la implementación de la Seguridad de SAP por personal del Grupo
Financiero para minimizar los costos significativos al no contratar proveedores externos con el
beneficio de no exponer la información sensible del Grupo

* Social
El proyecto de Tesis, tiene como finalidad poder mejorar los procesos de negocio de la
organización, teniendo como beneficio brindar la seguridad necesaria a la empresa.

Con este proyecto de tesis tiene la intención de asegurar toda la información contenida en SAP ya
que con esta implementación se cumple con los requerimientos mínimos requeridos por empresas
certificadoras para asi estar preparados cuando la empresa o Grupo Fianaciero requiera certificar
sus procesos en materia de Seguridad.

VII
INTRODUCCIÓN

Se realiza un estudio completo para determinar cual será el aplicativo a utilizar por el Grupo
Financiero Interacciones (GFI), derivado de un proyecto interno para renovar el core bancario que
se encuentra alineado a él Plan Director. Dicho proyecto nos determino que debemos contar con una
herramienta que cumpla con las directrices del plan y el proyecto, esto es contar con un core lo
suficientemente robusto, para lo cual se realizó una licitación que nos llevo a adquirir el sistema de
SAP.

Grupo Financiero Interacciones tiene sus antecedentes en 1981 cuando los accionistas actuales del
grupo adquieren la Corporación Mexicana de Valores. Desde ese entonces el grupo se ha
consolidado para poder proveer al mercado diversos productos en los que se encuentran: Casa de
Bolsa, Banco, Seguros y Fondos de Inversión.

Actualmente Grupo Financiero Interacciones está llevando a cabo el Plan Director el cual es un plan
estratégico de tecnología que se centra en el proyecto de Core Bancario. Su objetivo es optimizar
los servicios y productos financieros ofrecidos, de manera que agreguen valor y protección al
patrimonio de los clientes, y ofrezcan a GFI un marco tecnológico adecuado para que sus procesos
sean efectivos y eficientes.

En línea con el Plan Director y buscando trabajar bajo un marco tecnológico adecuado y de
procesos efectivos y eficientes, GFI ha iniciado con el proyecto SAP Solución Integral, con el cual
se busca dar soporte bajo una solución única de SAP a los procesos de finanzas, compras, gestión
de viajes y facturación, incorporando facilitadores tecnológicos como son Business Intelligence y
Portal de SAP. Esto permitirá además tener una base de datos central con la cual puedan atender de
una manera más eficiente sus necesidades de información. Esta plataforma tecnológica busca
también permitirle a GFI estar a la vanguardia para poder afrontar retos o requerimientos futuros.

Bajo el marco del Plan Director, el proyecto SAP Solución Integral debe compartir sinergias con el
proyecto del core bancario, de manera que se logre la integración de manera transparente de ambos
proyectos, resultando en una plataforma de procesos y tecnológica integrada.

1
Generalidades de SAP

SAP pertenece a una empresa alemana, y su significado en castellano es “Sistemas, Aplicaciones y

Productos en tratamiento de Datos”. El sistema SAP consta de varios módulos. Algunos de ellos
son:

FI: Finanzas
SD: Ventas y Distribución
MM: Gestión de Materiales
PP: Gestión de Producción
WF: WorkFlow
HR: Planificación y Recursos Humanos.

Estructura SAP

En general, los sistemas SAP tienen la siguiente estructura:

Ambiente de Ambiente Ambiente

Desarrollo Testing/Calidad Producción

Ambiente de Desarrollo: Aquí se realizan los desarrollos y parametrizaciones del sistema. Al

realizar un nuevo desarrollo, se genera una orden de transporte. Mediante la misma, el desarrollo
pasará a los demás ambientes.

Ambiente de Testing/Calidad: Los objetos generados en Desarrollo pasan a este ambiente por medio
de la orden de transporte. En este ambiente, se realizan las pruebas integrales para verificar el
correcto funcionamiento de los programas y parametrizaciones.

Ambiente Productivo: Aquí están los datos reales y es el ambiente con el que opera la compañía que
posee el sistema SAP.

2
Adicionalmente, puede usarse un ambiente Sandbox para testeo de configuraciones y desarrollos.

ABAP: el lenguaje de SAP

El lenguaje que se utiliza para programar en SAP es el ABAP. El ABAP es un lenguaje gobernado
por eventos, o sea, que existen eventos que condicionan la secuencia de ejecución de los programas.
ABAP es propietario de SAP, y no es un lenguaje en el que, como en otros (Visual Basic, C, etc.),
podemos realizar un ejecutable para correr en cualquier equipo. Los programas son ejecutables
dentro del ambiente SAP.
Netweaver: nuestro ambiente de desarrollo

Para programar, necesitamos conectarnos a un servidor SAP. Afortunadamente, en la actualidad

SAP nos provee un entorno para poder instalar en una pc y así tener una suerte de servidor
‘minisap’. Si bien en el mismo no encontraremos los diversos módulos que se encuentran en una
instalación real (SD, MM, FI, etc.), este entorno nos provee lo necesario para aprender a programar
y dar los primeros pasos en ABAP.

Transporte:

Cuando hablábamos de los distintos ambientes, decíamos que para pasar un desarrollo,
parametrización, corrección, etc., de uno a otro (ej., del ambiente de desarrollo al de testing), lo
hacíamos por medio de una orden de transporte. En las instalaciones reales, es siempre así, pero en
nuestro caso, tenemos un solo ambiente, y no generaremos nunca orden de transporte.

3
CAPITULO UNO

Objetivo

En este documento se establecen los principios y normas a seguir en la creación, administración y

asignación de roles y perfiles SAP a los usuarios del sistema.

El objetivo del mismo, es tener plenamente identificados los factores que influyen en la creación,
modificación, derivación y transporte de los Roles y Perfiles del sistema, así como el correcto uso y
asignación a los usuarios, tomando en cuenta su puesto organizacional, el área al que pertenece, así
como las actividades que realiza el usuario dentro de la empresa.

Ámbito de aplicación

El presente documento presenta las actividades y normas que se deben de cumplir por GFI para el
correcto uso y mantenimiento de la política de seguridad y asignación de permisos en el sistema
SAP. Buscando siempre el mantener los componentes básicos de la seguridad, aplicados a la
información:

 Confidencialidad: Garantizar que el acceso a la información y sistemas que la soportan

sólo sea por entidades o personas debidamente autorizadas.
 Integridad: Garantizar la exactitud de la información y los sistemas que la soportan contra
alteración, pérdida o destrucción, ya sea de forma accidental o fraudulenta.
 Disponibilidad: Garantizar que la información y los sistemas que la soportan puedan ser
utilizados por personal autorizado en la forma y el tiempo requeridos.
 Cumplimiento: Garantizar cumplimiento de la legislación vigente y estándares del sector
en materia de protección y seguridad de la información en todos sus procesos de negocio.

Documentos relacionados

Matriz de Roles

Desarrollo

Definición de Estrategia de Roles y Perfiles

El concepto de autorización, manejado dentro de los sistemas SAP, protege las transacciones,
programas y servicios de accesos no autorizados. La base de dicho concepto, es que el
administrador asigne las autorizaciones al usuario, dichas autorizaciones determinan lo que usuario
puede realizar dentro del sistema SAP, una vez que se ha firmado en el sistema.

Para acceder a los objetos de negocio, o transacciones de SAP, el usuario requiere contar con las
autorizaciones necesarias para dichas actividades. Las autorizaciones representan la instancia de una

4
autorización genérica que esta definida por las actividades o responsabilidades del empleado.
Dichas autorizaciones son almacenadas en un perfil, quien a su vez esta asociado directamente con
un Rol. El administrador de usuarios se encarga entonces, de asignar el Rol correspondiente al
usuario, con el fin de que pueda realizar sus actividades o tareas.

Existe una lista de Roles Simples Maestros, que contienen acceso a las transacciones que definen
las actividades de dicho Rol. Estos Roles Simples Maestros son la base sobre la cual se generarán
los roles “derivados” a los cuales se les restringirá las actividades sobre dichas transacciones u
objetos de organización.

Definición de Roles Simples Maestros

En el documento Matriz de Roles se encuentran definidos los Roles Simples Maestros, divididos
por módulo y por actividad a la que hacen referencia sus transacciones. Los Roles Simples Maestros
son la base para la “derivación” y agrupación de Roles SAP.

Esta función nace de un análisis funcional y de proceso

Durante la creación de los Roles Simples Maestros, solo se agregan las Transacciones a las cuales el
Rol hace referencia.

Su nomenclatura es ZS_(XX)_(YYYYYYYY)

Donde XX indica el módulo al que pertenece y YY la actividad a la que hace referencia el Rol.

En algunos casos se encontrarán las siglas ADM o ASI al final lo que indica que el Rol pertenece a
los usuarios Administradores o Analistas para el caso de ASI.

Roles Compuestos

Un rol compuesto, es un conjunto de Roles o GAD para realizar una tarea abarcativa de varios
puestos de trabajo. Los Roles compuestos son muy difíciles de mantener dado que se crean con un
propósito especifico y terminan siendo alterados por el desconocimiento del proceso, o por
directrices mal gestionada.

Segregación de Actividades

Las actividades o responsabilidades que cada uno de los usuarios tiene dentro del sistema, debe de
cumplir con la restricción de que un usuario no puede ser el dueño de más del 40% de las
actividades necesarias para liberar dicho proceso por completo; siempre y cuando dicho proceso se
vean involucradas diferentes áreas.

La segregación se generará adicionalmente por los objetos de nivel de organización que pueden
involucrarse en el proceso, la lista de Niveles de organización que se han tomando en cuenta son:

5
 Nombre Objeto
Sociedad BURKS
Grupo de compras EKGRP
Organización de Compras EKORG
División GSBER
Número de Almacén LGNUM
Organización de Ventas VKORG
Centro WERKS
Canal de Distribución VTWEG
Clase de Cuenta KOART
Sociedad CO KOKRS
Centro de Beneficio PRCTR
Puesto de Trabajo ARBPL
Entidad CP FIKRS
Variante de Plan PLVAR

Creación y Asignación

Solicitud de Creación o Modificación de Rol

Para la creación o modificación de un Rol deberá hacerse uso del formato “modificación de rol”en
el cual deberá de indicarse el módulo, transacciones, reportes y objetos de autorización que se
deben de incluir en dicho ROL. El formato deberá ser autorizado por la dirección de Información
Financiera y la Dirección de Seguridad Informática.

Una vez que se cuente con el documento de autorización se procederá a la creación o modificación
del ROL en cuestión.

Solicitud de Asignación

La dirección de Seguridad de la Información estará a cargo de la asignación de roles y permisos a

los usuarios, para ello se deberá hacer uso del formato “modificación de rol” para la asignación de
Roles a usuarios de sistema. Dicho formato deberá ser autorizado por la dirección correspondiente
al usuario, Recursos Humanos, la dirección de Información Financiera y la Dirección de Seguridad
Informática. Dicho procedimiento deberá de usarse para dar altas y bajas de roles a los usuarios.

Una vez que se ha recibido el formato autorizado, se procederá a la asignación del o los roles al
usuario. Este procedimiento deberá de ser utilizado del mismo modo en la “des asignación” de
Roles al usuario.

6
Administración

Ciclo de Vida de roles

Creación y Modificación de Roles

La creación y modificación de Roles y Perfiles deberá de cumplir con la estrategia de

mandantes del proyecto de implementación, dicha estrategia cuenta con los siguientes
principios:

-Creación y Modificación de Objetos, configuración y programación. Deberá realizarse en

el mandante 100 del ambiente de desarrollo

-Pruebas unitarias se realizarán en el mandante 110 y 120

-Pruebas Integrales, Calidad Mandante 200

-Asignación de producción Mandante 300

Derivación de Roles

Los Roles Simples Maestros deberán de tomarse como base para la derivación de nuevos roles,
modificando únicamente las actividades y permisos, así como los niveles de organización que sea
necesario ajustar de acuerdo a los permisos asignados al usuario.

La denominación de los roles Derivados va en función del nombre del Rol Simple maestro que se
esta derivando. Para ello el hombre de dichos roles derivados comenzará con las letras ZDX
(Derivado Ejecución) y ZDV (Derivado Visualización) estos son los únicos roles que pueden ser
asignados a usuarios finales.

Transporte de Roles

Los Roles deben de ser colocados en un transporte, para aplicarlos en los sistemas de Calidad y
Producción, esta prohibido modificar Roles directamente en el Mandante Productivo.

-Los roles se “transportan localmente” del mandante 100 al 110 y 120 mediante la transacción
SCC1, para ello es necesario que los roles se encuentre previamente “empaquetados” en un
transporte.

-Para realizar el transporte hacia los sistemas de Calidad y Producción es necesario realizarlo
mediante la transacción STMS, o en su defecto realizar la solicitud de transporte al área encargada
de los mismos.

-En el caso específico de la aplicación del transporte a Producción se deberá de contar con la
aprobación del Área de Sistemas de contabilidad, con el fin de notificar que la aplicación de los
cambios entrará en producción.

7
INTERACTUANDO CON EL SISTEMA

En esta sección vamos a ver las distintas transacciones que involucran a la seguridad en SAP R/3.
Algunas de ellas son de impacto directo, mientras que otras son de investigación en forma indirecta
a la seguridad.

Las transacciones a utilizar serán las siguientes:

1. PFCG (Profile Generador)

2. SU01 (Gestión de usuarios)

3. SU10 (Gestión de usuarios en masa)

4. SU53 (Datos de autorización para usuario)

5. SU56 (Autorizaciones en el buffer del usuario)

6. SU24 (Chequeo de objetos para transacción)

7. SE10 (Liberación de ordenes de transporte)

8. SE16 (Browser de tablas)

9. SE37 (Programas del sistema)

10. STMS (Sistema de transportes)

Las tablas que utilizaremos serán las siguientes:

1. ADCP (Datos de usuario)

2. ADRP (Datos de usuario)

3. AGR_DEFINE (Definición de GA)

4. AGR_USERS (Usuarios por GA)

5. AGR_TCODES (Transacciones por GA)

6. AGR_1016 (Autorizaciones por GA)

7. AGR_1251 (Datos de autorizaciones)

8. AGR_1252 (Niveles organizacionales en autorizaciones)

9. AGR_AGRS (Jerarquía de GA (Roles Compuestos))

10. TACT (Descripción de actividades)

11. TOBJ (Objetos del sistema)

8
12. TSTCA (Transacciones con valores estándar por objeto)

13. TSTCT (Descripción de transacciones)

14. USR02 (Usuarios del sistema)

15. USR05 (Parámetros de usuarios del sistema)

16. USR21(Datos de usuario)

17. USOBT (Objetos chequeados por transacciones (Standard))

18. USOBT_C (Idem anterior (Copia))

PFCG

La transacción PFCG (Profile Generador), es utilizada generalmente para la creación de Roles,

asignación de autorizaciones y eventualmente asignación de usuarios al Rol creado o modificado.
También se utiliza para remover usuarios de los Roles indicados por personal jerárquico.

Dicha transacción, tiene muchas mas funcionalidades que serán vistas a los largo de este punto. En
la figura observaremos la pantalla de inicio de la transacción.

Figura 1

Como podemos observar, en la pantalla principal de la transacción, además de tener múltiples

opciones, podemos crear, modificar, visualizar o borrar un rol.

9
Nomenclatura de Roles

Tanto para la creación de nuevos Roles, como transacciones, objetos de autorización, etc., SAP,
deja a disposición de los usuarios las letras “Y” y “Z” para este caso se tomara la nomenclatura
ZDX_XXX.

De esta manera, es muy simple detectar los Roles que no son estándar de SAP, y en función de
ello, poder realizar el análisis correspondiente ante cualquier situación. No olvidemos, que los
desarrollos estándar de SAP NUNCA comenzaran con las letras anteriormente descritas.

Igualmente, no hay una regla de oro para la nomenclatura que utilicemos, para este caso preciso,
utilizaremos la denominación PRUEBA, cuya inicial no es “Y” ni “Z”.En los casos prácticos
(Servidores DEV – QUA - PRD) inexorablemente deberán comenzar con las letras antes
mencionadas.

En el caso de que los mismos Roles no comiencen con las letras que mencionamos anteriormente,
funcionaran y no habrá ningún tipo de problemas en cuanto a la funcionalidad de los mismos. Pero
hay que destacar, que se esta saliendo del estándar y ello puede traer consecuencias para los futuros
administradores del sistema.

Creacion de un Rol Simple

En la figura 2 observaremos la creación de un GA. Para ello, debemos ingresar el nombre del Rol
en el campo ROLE y luego presionar el botón que se encuentra a la derecha denominado ROLE.

10
 Figura2

Podemos observar que una vez creado el Rol, pasamos a ver una serie pestañas en donde podemos
definir el menú del usuario, las Autorizaciones para las transacciones que posee en el menú y la
asignación a el/los usuarios que harán uso del Rol creado. Veamos paso por paso como se
construye un grupo de actividad.

En la pestaña “Descripción”, daremos detalle de que se trata el Role para futuros cambios a los que
pueda ser sometido el Rol. A continuación, en la figura 3 y 4veremos los dos primeros pasos
descritos anteriormente.

Figura 3

11
Como podemos ver, la descripción queda a la entrada al Rol, vale decir, que de ahora en mas
cuando queramos modificar el Rol, lo primero que nos aparecerá en pantalla es la pantalla de la
figura 3.

Pestaña Menú

Haciendo un clic en la pestaña “Menu”, nos encontraremos con la pantalla de la figura 4, donde
podremos hacer múltiples configuraciones, yendo desde la mas básica (Manual) hasta copias del
menú de otros Roles.

Figura 4

El paso a seguir, es incorporarle transacciones al nuevo Rol, dado que la configuración actual no
nos es de mucha utilidad.

12
Asignación de transacción – Modo estándar

Para agregar una transacción, haremos un clic en el botón ,donde nos aparecerá a modo POP-UP la
pantalla de la figura 5.

Figura 5

En los espacios en blanco, definiremos las transacciones que queremos que formen parte del grupo
de actividad, en este caso, solo hemos incorporado la transacción SM37 como ejemplo practico.

Para que la transacción sea confirmada en el Rol, debemos hacer un clic en el botón “Asignar
Transacción.

A partir de ese momento, la transacción empieza a formar parte del Rol lo que no quiere decir que
la misma se encuentre operativa para su uso. Mas adelante configuraremos la puesta en marcha de
las transacciones asignadas.

13
Asignación de transacción – Desde el menú de SAP

Ahora, vamos a incorporar una transacción desde el menú sap. Para ello, debemos hacer clic en el
botón “From the SAP menu” . Ante este evento, nos aparecerá una pantalla a modo POP-UP como
se ve en la figura 6.

Figura 6

En esta pantalla podremos seleccionar las transacciones a partir del menú SAP. Las mismas, están
ordenadas en carpetas y bajo ese mismo esquema es como las importara. Veamos un ejemplo en la
figuras 7 y 8.

14
 Figura 7

Como vemos en la figura 7, hemos seleccionado la transacción SM02 a través del menú estándar de
SAP. Para que la misma comience a formar parte del GA, debemos hacer un clic en el botón
“Transfer” .Como mencionábamos anteriormente, en la figura 8 veremos la incorporaron de las
transacciones seleccionadas por los dos primeros métodos.

A continuación veremos los métodos restantes.

15
 Figura 8

Ahora veamos los tres métodos restantes que son de gran utilidad a la hora de simplificar trabajo en
el diseño de Roles. Comúnmente, estos métodos no son utilizados ya que los mantenimientos se
realizan en forma manual. Lo ideal seria mantener el esquema propuesto por SAP, ya que de esta
manera, los Roles se convierten en estándar para una empresa.

Asignación de transacción – Desde un Rol

El siguiente método que vamos a investigar es el de tomar transacciones desde otro Rol que
conozcamos. Como todos sabemos, SAP en la instalación, deja Roles genéricos creados para su
utilización. Estos Roles son los que propone para la utilización del sistema, dado que los mismos
están normalizados y las funciones se encuentran correctamente segregadas.

En la figura 9, vamos a trabajar con el menú de un GA estándar de SAP. Cuando apreciemos la

pantalla, podremos observar que prácticamente no difiere en relación al método “From the SAP
menú”.

Para comenzar con este método, debemos hacer un clic en el botón “from other role” . En ese
instante, nos aparecerá una pantalla a modo de POP-UP tal como vemos a continuación.

16
 Figura 9

En esta pantalla, podremos optar por seleccionar entre “Single Roles” o “Composite Roles”. En
nuestro caso vamos a continuar tal cual nos aparece la pantalla. En el campo “Single Role”
debemos colocar el nombre del GA que queremos utilizar como referencia para el menú. Si
desconocemos este, debemos hacer un clic en el botón. Como nosotros no tenemos conocimiento
del Rol a utilizar, procederemos a tomar la acción antes descripta. En ese momento, el sistema
arrojara una pantalla como muestra la figura 10.

Figura 10

17
En la figura 10 observamos gran parte de los grupos de actividad creados en el sistema. Ahí,
seleccionamos el GA al que deseamos para heredar el menú y luego hacemos clic en el botón . En
nuestro caso, hemos seleccionado el Rol. SAP_ACH_ADMIN.

En la figura 11, observamos una pantalla muy similar a la de la figura 6.

Figura 11

Si comparamos con detenimiento las figuras 6 y 11, vemos que la diferencia es perceptible dado
que en la cabecera de una pantalla y otra, lo único que varía es “SAP estándar Menu” por
“SAP_ACH_ADMIN”. El resto, salvando las distancias de las transacciones asignadas, es
prácticamente similar.

18
Una vez seleccionada la transacción que se adecuaba a nuestro Rol, haremos clic en el botón “Add”.
Antes de ver como quedo plasmada la transacción en el Rol, veamos los últimos dos métodos que
nos quedan. El método que a continuación veremos, es el de incorporar un área del menú.

Difícilmente utilicemos esta opción, aunque es muy útil en las reingenierías de seguridad ya que
podremos decir con exactitud los procesos de cada área siempre que el dueño de los datos este de
acuerdo con el método a emplear.

Para comenzar, debemos pulsar el botón “From area menu”.

En la figura 12 veremos un pop-up que solicitara algunos datos.

Figura 12

Muy probablemente, las áreas de menú lo las conozcamos o no estemos familiarizado con lo cual
pulsaremos el botón para que el sistema no de un resumen de todas las áreas creadas hasta el
momento.

19
La pantalla arrojada por el sistema es como la que podemos observar en la figura 13.

Figura 13

Seleccionaremos la primera área de menú y veremos la pantalla tal como muestra la figura 14.

20
 Figura 14

Esta pantalla, que como vemos es similar a la de la figura 6 y 11, y la operación en la creación de
roles es exactamente igual a las dos anteriores. Lo único que difiere es la asignación del área en
cuanto a que no es una transacción, si no que es un área de transacciones. Esto es exclusivamente
así cuando seleccionamos toda el área como lo haremos nosotros.

Asignación de transacción – Desde un archivo TXT

Por ultimo, resta ver como armar el menú de transacciones desde un archivode texto. Cabe destacar,
que esta opción no tiene una frecuente utilización. El caso donde se aplica con frecuencia esta
modalidad, es en la recopilación de roles tanto en reingenierías como puestas en marcha.

21
La aplicación que genera la salida del archivo TXT podría ser una macro en Excel, o bien, un
desarrollo propio.

A continuación, veremos el esqueleto del archivo TXT, con el fin de poder tomarlo como template
para futuras implementaciones. Los ejemplos a mostrar son para la implantación de transacciones
con y sin carpeta.

Esqueleto de archivo TXT con transacción en carpeta:

FORMAT 1.2B

NODE 000030000100001FOLDER

TEXT 00003ENAdministration of role

NODE 000060000300003TRANSACTION PFCG

TEXT 00006ENProfile Generator

El archivo esta compuesto en este caso, por cinco (5) líneas. La primera de ellas, cumple la función
de cabecera del archivo. Algo que no nos aporta mucho, pero que el sistema interpreta.

La segunda línea, denominada NODE, cumple la función tal como su denominación lo dice
“NODO”, pasándole cuatro parámetros. El primero, es el ID por el cual va a tener nombre la
carpeta, el segundo y tercero indica el nodo predecesor, y el cuarto indica que tipo de nodo será.
Veamos como funciona:

NODE 00003 00001 00001 FOLDER Esta linea marca los cuatro parámetros que comentaba
anteriormente.

El primero de ellos (00003) es el ID con el que llamara a la etiqueta TEXT. Luego, aparecen dos
grupos de parámetros (00001 00001) donde nos muestra la hoja o el nodo padre, en este caso:
FORMAT 1.2B.

El cuarto parámetro denominado FOLDER, nos indica que el nodo será una carpeta que contendrá
una o un grupo de transacciones.

TEXT 00003 EN Administration of role indica que se trata de una etiqueta 00003 es el
ID de la etiqueta, llamada desde el nodo FOLDER, EN indica el idioma con el que
estamos trabajando (podría contener múltiples líneas con el mismo ID pero diferente
identificador de idioma), y Administration of role, indica el nombre de la carpeta.

NODE 00006 00003 00003 TRANSACTION PFCG indica un nuevo nodo que tiene como padre
al 00003. Vale decir, que este nodo estará por debajo del nodo FOLDER con una jerarquía menor.
Pero este nodo es del tipo TRANSACTION, con lo que deberemos indicarle un nuevo parámetro,
que en nuestro caso es PFCG.

22
Si lo pasamos en limpio, tendremos una transacción (PFCG) dentro de la carpeta
ADMINISTRATION OF ROLE. Lo único que resta es la etiqueta TEXT para identificar la
transacción. Se los dejo para que lo hagan ustedes. Procuren no copiarse del ejemplo anterior. En la
figura 15 veremos el proceso de finalizado.

Figura 15

Pestaña de Autorizaciones

En esta pestaña vamos a configurar las autorizaciones que tendrá el usuario o el grupo de usuarios
para las transacciones que existen en el menú. En primera instancia, observaremos como se
compone la solapa y luego iremos a la configuración propiamente dicha. En la figura 16 tenemos
una visión de la misma..

23
 Figura 16

Como podemos apreciar, esta pantalla nos es mas que informativa. Tenemos datos como:

1. Creador de la autorización (No del Rol)

2. Ultimo usuario que ha realizado un cambio

3. Nombre del perfil

4. Status (Generado, Necesita Ajuste, etc.)

5. Botón de modificación de autorizaciones.

Configuremos las autorizaciones. En las siguientes figuras veremos la configuración de

autorizaciones, pasando por los niveles organizacionales, estados de los objetos y significado de las
actividades más relevantes.

NIVELES ORGANIZACIONALES

Los niveles organizacionales componen una parte fundamental del sistema SAP. Los mismos, son
parame trizados post instalación del sistema acorde a los módulos solicitados. Estos valores son
permanentes en el sistema, y como decíamos anteriormente ,se definen a media de que se
parametriza el modulo, que no quiere decir que en el futuro no puedas ser agregados, modificados o
borrados.

El sistema viene con niveles organizacionales por defecto, que si bien nunca son utilizados, para
este curso nos servirán de ejemplo. En la siguiente pantalla ,veremos que los niveles

24
organizacionales aun no fueron configurados. En este tipo de situaciones, el sistema arroja la
siguiente pantalla como ilustra la figura 17.

Figura 17

El MATCH CODE, si lo pulsamos, no traerá todos los datos relacionados con el campo a
completar. En este caso, el campo a desplegar es el de COMPANY CODE, tal como ilustra la figura
18.

25
 Figura 18

En esta pantalla, seleccionaremos aquellas compañías o sociedades que debemos asignar al Rol.

En la figura 19, observaremos los distintos estados de los objetos de autorización. Esta
nomenclatura es fundamental tenerla presente a la hora de trabajar con Roles dado que el status nos
indica a primera vista, que datos nos están faltando.

Figura 19

Si observamos con detenimiento, el semáforo general se encuentra en ROJO,

y los que están en el árbol poseen dos estados, ROJO y AMARILLO. Vemos de qué se tratan estos
estados.

Semáforo Rojo Significa que están faltando valores ORGANIZACIONALES (Figura

17).

Semáforo Amarillo Significa que están faltando valores NO ORGANIZACIONALES, tales

como por ejemplo: ACTIVIDAD.

26
El Semáforo en Verde Significa que los valores para el objeto están completos.

Ahora pasemos a ver los objetos desplegados. En ellos encontraremos una serie de valores a cargar
según las tares que se hayan definido para el grupo de actividad (GA). En la figura 20, veremos lo
explicado en detalle.

Figura 20

Observemos que los desplegados son los que están en AMARILLO y uno VERDE. Cada uno de
estos objetos esta faltante de datos, pero es como SAP presenta de forma Standard. Si nos remitimos
a la figura 19 podremos ver lo antedicho.

Cuando se realiza la modificación de un objeto, el mismo cambiara este status, ya que se estaría
violando el Standard SAP. El nuevo status del objeto y grupo de objetos para a ser MAINTAINED.
Veamos la figura 21.

Figura 21

Si observan con detenimiento, el primer grupo de objetos figura en MAINTAINED dado que en el
interior del mismo, se ha modificado un objeto. En la figura 22 vemos este grupo de objetos
desplegado.

27
 Figura 22

En algunos casos, los objetos de autorización que figuran en nuestro Rol, no son suficientes para
que la transacción ejecutada cumpla con el espectro funcional que se desea. En estos casos, se
deberán incorporar de forma manual, aquellos objetos solicitados por el sistema, tanto por un
reporte con la transacción SU53 o en su defecto, a través de un trace con la transacción (ST01).

Cuando insertamos un nuevo objeto manualmente, el mismo presenta el status MANUALLY. Esto
quiere decir que debido a un incidente o por análisis surgió que el objeto debería estar en el Rol que
estamos modificando.

En la figura 23 veremos como se ve el grupo de objetos al que le hemos agregado un objeto.

Figura 23

En la figura 24 veremos el grupo de objeto FI desplegado para ver que objeto fue incorporado al
Rol.

28
 Figura 24

Como vemos, el objeto agregado manualmente figura como tal, pero el grupo de objetos figura
igual. Esto es muy interesante ya que a primera vista podremos observar si alguien hizo
modificaciones manuales. Este status no es más que una inserción de un objeto y el mismo, no
ocasiona ningún problema. Lo único que debemos tener en cuenta, es que el objeto a insertar, no
genere conflictos funcionales o por contraposición de funciones.

Una vez cargado todos los datos de autorización, los semáforos se posicionaran en color verde. Esto
conlleva a generar la autorización y a posteriori, asignarlo al usuario correspondiente. En la figura
25 vemos el grupo de objetos cargados.

Figura 25

Con esta explicación grafica se entenderá mas fácilmente el funcionamiento y los pasos a seguir
para asegurar que el proyecto cumpla con su objetivo.

Dentro del proyecto asignado a mi persona se derivaron muchas dudas ya que como lo repito no hay
muchas fuentes confiables para basarse en una técnica apropiada en la construcción de Roles para
cada uno de los módulos adquiridos para el Grupo Financiero.Para realizar la creación de Roles y
Perfiles de cada uno de los módulos se conto con el apoyo del líder funcional certificado por SAP y
el dueño del proceso que apoyara con la información de cada Área involucrada en el proyecto.

29
PLAN DE TRABAJO

El plan de trabajo adoptado por el Grupo Financiero Interacciones fue denominado “Big Bang”

Es decir, el arranque se realizará en todas las áreas involucradas dentro del Alcance de este
proyecto para que den inicio a sus operaciones en productivo al mismo tiempo y posteriormente se
considere un periodo de soporte y estabilización.

Considerando los tiempos y necesidades planteadas por el Cliente, se ha realizado un esfuerzo para
acotar el Alcance y la estrategia de implementación del Proyecto. La duración de cada fase del
Proyecto se prevé y estima de la siguiente manera:

Figura 26

Fase 1. Preparación de Proyecto

Comprende el diseño y realización de la sesión de arranque del Proyecto (“kick-off”) con
todo el equipo de Implantación. Para este punto ya se debe tener definido el organigrama final
del equipo de trabajo, la misión, objetivos, roles y responsabilidades de cada miembro, así
como un alcance de Proyecto detallado y el plan de trabajo detallando las actividades por
cada fase del Proyecto.
Esta definición es responsabilidad compartida tanto del gerente de Proyecto de SAP como del
gerente que el Cliente designe para este proyecto.
Fase 2. Planos del Negocio
Cubre el entendimiento detallado de los requerimientos del Proyecto para determinar juntos
los procesos de negocios necesarios para cumplir con los requerimientos de información,
identificándose en esta etapa la funcionalidad que será incluida en la construcción. Esto se
logrará mediante la documentación de los requerimientos, usando cuestionarios y revisando
los procesos de negocios con el personal de SAP. La documentación obtenida aquí es llamada
planos del negocio, la cual incluye organigramas, diagramas de procesos y respuestas a
cuestionarios resueltos con usuarios; dicha documentación deberá aprobarse como punto de
partida para la siguiente fase.

30
En esta fase es necesario contar con la participación de usuarios del Cliente que conozcan a
profundidad los procesos a ser analizados. Es responsabilidad del equipo de proyecto SAP y
del Cliente guiar las sesiones de planos de negocio y, al final de la fase, contar con un
documento validado y firmado por las personas que participaron en las reuniones de trabajo.
Fase 3. Realización
Durante esta fase, el equipo de Proyecto, con la información colectada en la fase anterior,
construirá la configuración del sistema, que represente los procesos de negocios incluidos en
el alcance, interfaces, conversión de datos, etc., así como definir los criterios de aceptación de
la funcionalidad configurada por los usuarios. En la siguiente etapa se validará la
funcionalidad de este prototipo con los usuarios finales.
En esta fase se contará con el modelo del estado futuro de las operaciones, mediante sesiones
de validación con el equipo de proyecto, usuarios clave y el personal de SAP, quienes
llegarán a consensos acerca del criterio de aceptación de cada proceso configurado.
Durante estas sesiones de trabajo el equipo de proyecto por parte del Cliente estará trabajando
estrechamente con los especialistas de SAP para definir los escenarios de negocios que
deberán ser cubiertos por la funcionalidad estándar o bien por desarrollos complementarios y
la configuración se hará de manera conjunta. Otro propósito: terminar las pruebas con los
usuarios clave, así como pruebas unitarias y pruebas integrales.
Es responsabilidad del equipo de consultores integrado por SAP documentar la configuración
llevada a cabo durante esta fase.
También es parte medular de esta fase, la sesión extensiva de pruebas a las que denominamos
pruebas integrales, es decir son escenarios de negocio reales que son simulados en el sistema
y con los cuales estaremos garantizando el funcionamiento óptimo del sistema con la
configuración final para el Cliente.
Fase 4. Preparación final y puesta en marcha
En esta fase se hace la capacitación a usuarios finales con material preparado en la fase
anterior por el equipo especialista del Cliente, se prueban los datos finales, procedimientos y
programas desarrollados en la fase anterior y pruebas de aceptación final. Se creará una
estrategia de puesta en marcha, se probará el sistema y se asegurará que esté listo para puesta
en marcha en la fecha planeada.
Es responsabilidad del equipo de usuarios clave del Cliente preparar el material de
capacitación a usuario final e impartir dichas capacitaciones, para esto se contará con el
apoyo y asesoría del equipo de consultores integrado por SAP.

31
 Fase 5. Puesta en marcha y soporte post - arranque
Inmediatamente que el sistema se ponga en marcha, deberá ser revisado y afinado para
asegurar que el entorno del negocio está completamente soportado, incluyendo, la precisión
de los datos cargados, convertidos, reportes, seguridad de acceso, medir constantemente los
beneficios obtenidos del uso del sistema por parte del negocio, etc.

Metodología de manejo del proyecto

De la misma manera se utilizará la metodología PM (Project Management) para el manejo del

Proyecto. La metodología de Project Management de SAP está basada en estándares
internacionales certificados por el Project Management Institute en su PMBOK Guide,
combinando procesos que han mostrado ser exitosos en las etapas de inicio, planeación,
ejecución, monitoreo, control y cierre en proyectos alrededor del mundo.
El alcance general de la metodología PM puede ser visualizado como cuatro fases separadas,
pero estrechamente relacionadas:

Evaluación

En la fase de evaluación se inicia la recolección de documentación pertinente al Proyecto.

PARTICIPACION

La fase en las cuales se aportaron los conocimientos de Seguridad y Control fueron las Fase 4 y 5
respectivamente.

El proyecto desde su inicio fue muy ambicioso ya que con la carga de operación diaria y la falta de
personal se lograron casos de éxito en corto tiempo.

Gracias a la participación conjunta del responsable del área y el líder certificado por SAP se logro
identificar acertadamente las transacciones principales de cada uno de los procesos operativos
dentro del Grupo Financiero.

Con ayuda del formato “Pruebas integrales” se tuvo un avance gratificante ya que en ese formato
se engloban los flujos o procedimientos descritas por cada área y el funcional Certificado lo
traducía en transacciones estándar de SAP.

32
Ejemplo del formato de Pruebas Integrales.

Figura 27

IMPLEMENTACION Y CREACION DE ROLES

Para la creación de roles y perfiles se crearon usuarios de prueba en el ambiente de QA (Pruebas)

este ambiente es controlado ya que no existen datos reales de la empresa para la seguridad del
grupo se dieron datos ficticios para poder realizar las pruebas de cada modulo.

Con la información obtenida por cada uno de los funcionales certificados por SAP y el responsable
de cada área se logro implementar le siguiente matriz de actividades dividiéndola en dos partes la
primera en Levantamiento de información de cada Area y la segunda parte en pruebas preliminares
estas actividades empezaron el julio y terminaron en Octubre del 2011.

Fase 1

Tabla 1

33
Fase 2

Tabla 2

MATRIZ DE PRUEBAS

En esta matriz se ejemplifica las pruebas realizadas antes de liberarlas en productivo en esta
imagen se encuentra las funciones principales de cada rol para cada una de las personas
involucrada en el proyecto de implementación véase tabla 3.

Tabla 3

Los roles se nombraron como lo recomienda SAP en este caso de opto por la letra “Z” a si mismo se
dividieron en tres sub roles los cuales son los siguientes

ZS: Rol (padre) En esta nomenclatura se encuentran alojadas exclusivamente transacciones de cada
proceso verificado por cada funcional de modulo certificado la ventaja en esta nomenclatura es que
se podrá realizar copias si es que el área lo requiere.

ZDX: Rol derivado de ZS en esta nomenclatura se encuentran las autorizaciones exclusivas de cada
proceso por lo que de un control mas acertado en las actividades especificas de cada rol.

34
ZDV_ Esta nomenclatura nos indica que es un rol derivado de ZS pero con la actividad de solo
lectura este rol es importante ya que por requerimientos de dirección se creo ya que existen áreas
que solo requieren visualizar la información contenida en SAP.

Como se ejemplifica en la siguiente tabla 4

ERRORES

En cada implementación de cualquier sistema existe la posibilidad de encontrarse con errores que a
veces los mismos proveedores desconoce por lo que se les dará una breve explicación técnica para
la solución de errores en transacciones en SAP.

Todas las transacciones de SAP para cualquier modulo están relacionadas entre si directamente o
indirectamente.

Para esto se utilizara la transacción su53

La transacción SU53, es de suma utilidad a la hora de investigar los problemas de seguridad de los
usuarios. El mismo, genera un reporte con el último evento generado por el usuario, vale decir, que
si un usuario ejecuta una transacción que no tiene asignada, el sistema arrojara un mensaje de error
informando que no posee autorización para ejecutar dicha transacción.

Esta transacción es de suma importancia para el responsable de la seguridad de SAP ya que sin esta
transacción seria imposible detectar el problema de autorizaciones, por lo que es recomendable que
se genere un rol con esta transacción exclusivamente y sea asignada a todos los usuarios de SAP

En la siguiente figura se muestra en forma grafica la transacción SU53

35
 Figura 28

En la primer sección del reporte, nos indica que autorización esta haciendo falta. En este caso,
solicita para la clase de objeto AAAB, el objeto S_TCODE, el valorMK01.

En este caso, el valor MK01, no debe ser cargado a mano en el objeto ya que en los mismos se
contemplan variables. Si llegáramos a modificar manualmente este campo, cada vez que
agreguemos una transacción por menú, la misma, no será cargada en el campo del objeto
S_TCODE. Lo mismo sucede, si lo que estamos modificando manualmente es un Nivel
Organizacional. Mas adelante veremos este caso.

Para nuestro caso con la ayuda de este reporte de la transacción SU53 los problemas de
autorizaciones se realizaran en los Roles denominados ZDX exclusivamente.

36
PLANEANDO LA INSTALACIÓN

Se recomienda tener a mano el Manual de Instalación de SAP R/3 4.6C bajo Windows 2000 y
Oracle para ir siguiendo los pasos de la instalación.

Chequeando necesidades de Software y Hardware

El servidor de la implementación cumple con los requisitos mínimos de más de 20 Gb de espacio en

al menos tres discos separados (en nuestro caso particiones). No cumple con los 512 Mb de
memoria RAM, pero para un entorno no productivo como el de desarrollo servirá.

Nota: El espacio requerido para la copia de los mandantes sobrepasa al espacio en disco del
servidor.

En nuestro caso, vamos a instalar sobre Windows 2000 Advanced Sever, y es recomendable que
tenga instalado hasta el Service Pack 3. Sobre todo, es necesario que esté sobre NTFN o no podrá
ser instalado.

Puesto que queremos instalar localmente, si la máquina pertenece a un dominio lo más sencillo sería
sacarla de él y si el servidor en el que se va a instalar está configurado como Controlador de
Dominio de Windows2000 será necesario que deje esa funcionalidad.

Comprobando la red

Se comprueba el correcto funcionamiento de la red en el equipo así como que responde a su nombre
de máquina con el comando ‘ping’.

Ejecución:

- Abrimos una ventana de línea de comandos, y escribimos ipconfig para conocer la ip del servidor.

- Seguido, escribimos el comando ping sobre esa dirección.

- Pulsamos Windows + Pausa, y nos aparecerá la ventana de Propiedades del Sistema. En la pestaña
Identificación de Red, miraremos el nombre del servidor.

- Ahora, hacemos ping sobre el nombre del servidor, es importante que la red esté perfectamente
configurado, puesto que las conexiones SAP se realizan a través de TCP-IP.

Distribución de los componentes en los discos

Para la instalación de R/3 se dispone de la siguiente distribución de espacio en disco:

C:\ Partición del Sistema Operativo

37
E:\ Partición donde irá la Base de Datos

D:\ Partición donde irán los binarios

En C:\ no vamos a instalar nada, aunque se crearán carpetas para usuarios y se modificarán dlls, se
añadirán claves al registro, etc.

En E:\, por ser la unidad más grande, va a albergar la base de datos de SAP que viene a ocupar
cerca de 10 Gb en la instalación y que aumentará su tamaño al importar los lenguajes y copiar los
mandantes. La base de datos cuenta con los siguientes componentes: SPACHEK, SAPBACKUP,
SAPTRACE, SAPREORG, SAPARCH, SAPDATA1, SAPDATA2, SAPDATA3, SAPDATA4,
SAPDATA5, SAPDATA6, MIRROLOG B, ORILOG A. En D:\ vamos a instalar los binarios de
Oracle y los de SAP, así como el SAPGUI y el R3SETUP. Además, contendrá las carpetas
MIRROLOG A y ORILOG B. En el caso de los MIRROLOG y ORILOG, las parejas tienen que
estar en unidades distintas

Directorios creados durante la instalación

Se crearán los siguientes directorios durante la instalación:

- D:\usr\sap, que contiene el software principal de SAP

- E:\oracle\BPM, que contiene la base de datos SAP

- E:\transportes\implementación, que contendrá el sistema de transportes de SAP

- C:\Documents and Settings\bpmadm, que es el perfil del administrador SAP

- D:\SAPpc , aquí irá la instalación del SAPGUI

- D:\oracle\bpm\817, contendrá los binarios de Oracle

- D:Users\bpmadm\Install , contendrá la herramienta R3SETUP

PREPARANDO LA INSTALACIÓN

CDs de Export

Copiamos en E:\, los CDs necesarios para la instalación (Los cuatro cds de Export) debido a que la
instalación va a necesitar que le facilitemos su ruta.

_ E:\Export1 .... Export4 Teniéndolos copiados en local nos aseguramos de poder dejar la
instalación desatendida durante varias horas.

Nota: Los cds de Export contienen la base de datos de SAP.

38
Instalando DLLs Actualizadas para el Sistema

Hay que realizar una actualización previa de algunas DLLs del sistema, para lo que se ejecuta el
programa r3dllins desde el CD del kernel del R/3. En caso de necesitarlo, se reiniciará el sistema.

Memoria Virtual

Se precisan al menos 4 veces la memoria RAM, aunque más de 10 GB no son necesarios. Para
cambiar la memoria virtual:

- Pulsamos Windows + Pausa, y nos aparecerá la ventana de Propiedades del Sistema.

- En la pestaña Avanzado, pulsamos en Opciones de Rendimiento y, donde dice Memoria Virtual

damos a cambiar.

- Multiplicamos 128 x 4 : 512 Mb necesitamos de RAM como mínimo, y como máximo le

pondremos 720 Mb para no quedarnos sin espacio en el disco duro. Si fuera muy muy mal el
servidor, siempre podemos ampliarlo a 848.

Usuario y Permisos para la Instalación

Como es una implementación, podemos hacer la instalación con el usuario Administrator,

que es el administrador del servidor, pero en caso de querer podríamos crear un nuevo

usuario, por ejemplo, Instalador, y darle los mismos permisos que a Administrator

Nombre del SAP System y del Servidor

La instancia de SAP que se va a instalar, según los requerimientos del implementación se

llama BPM, y el servidor de la instalación será SERVIDOR

Nota:

Es el nombre que tenía por defecto y como cumple la norma de que los

nombres de servidor que albergan las instancias no pueden tener más de nueve

letras lo dejamos así

2.6 Preparando el directorio de Transportes

Creamos el directorio de Transportes tal y como se requiere en la implementación:

E:\Transportes\implementación

Y compartimos la carpeta Transportes, dándole el nombre de recurso compartido

39
Sapmnt2

Ejecución:

- Desde el explorador de Windows, vamos a E: y creamos la nueva

carpeta.

- Pinchamos con el botón derecho sobre ella, y elegimos Compartir

- En la nueva ventana, elegimos Compartir esta carpeta, y le ponemos

de nombre Sapmnt2

- En la pestaña Seguridad, agregamos el grupo Todos

INSTALACIÓN DEL SISTEMA SAP

Una instalación SAP se compone de

- Instancia Central de SAP

- La Base de Datos

- Los frontends de SAP

- Si hacen falta, instancias de Diálogo, de Batch, de Spool.....

Nota:

Una instancia es una instalación completa de R/3 + base de datos, y puede

haber una instancia por cada tipo de proceso excepto el de enqueue y el

mensajero, que están siempre en la instancia central

Un mismo servidor puede albergar tantas instancias como sea capaz de

hacer funcionar, de modo que podríamos tener en un mismo host la instancia

central con su base de datos central y además dos instancias de diálogo, por

ejemplo.

En la implementación vamos a ver la instalación del Sistema SAP en una sola

instancia, es decir, vamos a tener una Instancia Central con su Base de datos y

su frontend, pero no tendremos instancias especializadas

40
Instalación del software de Oracle

El Oracle que funciona con SAP es algo diferente del Oracle normal, y es por eso

que se distribuye con las instalaciones y también por lo que han creado unos

instaladores específicos

La instalación de Servidor es la nuestra porque en nuestra máquina vamos a tener

una instalación de Instancia Central más Instancia de Base de Datos.

La instalación de Cliente se haría en caso de tener una máquina dedicada

exclusivamente a la Base de Datos, en cuyo caso tendríamos que instalar en dicha

máquina el servidor de Oracle y en la máquina de la Instancia Central, el cliente de

Oracle.

Cualquier instancia que no esté en la misma máquina que la de Base de Datos,

tiene que tener instalado el Cliente Oracle y no el Servidor.

_ Escogemos el cd de software Oracle para Windows y lo exploramos para llegar

a la ruta

<Unidad>:\NT\I386

Veremos que hay tres ejecutables, sapserver.cmd, sapclient.cmd y el Universal

Installer normal. Haremos doble clic sobre sapserver.cmd

El nombre de la instancia a crear es: BPM, y la ruta de instalación es

D:\Oracle\BPM\817

Nota:

Es importante que el SID de la base de datos sea de tres letras, por que

el SAP no nos lo admitirá si no es así

Una vez haya terminado de instalar Oracle (la barra de estado siempre va a estar

al 100%), paramos los servicios que ha creado

Ejecución:

- Inicio / Programas / Herramientas Administrativas _ Servicios

41
- Buscamos los servicios de Oracle y paramos aquellos que están en

automático dando al botón parar

A continuación instalamos el parche de Oracle 8.1.7.0.1 para Servidor, que se

llama sap81701svr.exe y está en el mismo cd de la instalación en

<Unidad>:\NT\I386\Patches\8.1.7.0.1

Como se puede observar, es un auto descompresor, y hay que darle la ruta donde

hemos instalado los binarios de Oracle, es decir, en D:\oracle\BPM\817 porque tiene

que sobrescribir los archivos

Por último deberemos volver a levantar los servicios de Oracle que paramos

anteriormente

Instalando R3SETUP

El R3SETUP es la herramienta que va a instalar SAP en el equipo, de modo que

tenemos que instalarlo primero desde el cdrom del Kernel de SAP

Ejecución:

- Iniciamos el programa R3SETUP.BAT que está en el directorio

<Unidad>:\NT\common. Aparecerá una ventana

- Le damos el nombre del SAPSID: BPM

- Le damos el directorio donde queremos que nos copie el instalador,

que es en D:\users\bpmadm\install

Una vez hayamos de terminado de rellenar todas las entradas que nos pide, se

instalará automáticamente y nos pedirá autorización para hacer logoff. Le diremos que

sí y volveremos a entrar y de ese modo nos habrá creado en Inicio/Programas un grupo

llamado Sap System Setup for BPM, desde el que podemos comprobar que se pueden

lanzar todo tipo de instalaciones de SAP R/3.

Instalando SAP y cargando la Base de Datos

Desde el grupo de Programas Sap System Setup for BPM, ejecutamos la

42
opción de Instancia Central y Base de Datos, y se nos abrirá una ventana del R3SETUP

que, cuando haya completado su 100% habrá creado la Instancia Central, la Instancia de

Base de datos y la habrá rellenado con datos

La herramienta R3SETUP nos va a pedir una serie de parámetros detallados a

continuación:

Nota:

El último parámetro lo pedirá horas después de haber pedido el resto

PARÁMETRO VALOR

SAP System Name BPM

Instance Number 00

Domain selection \\servidor

Name of the Central Transpor Host servidor

Database System Name BPM

Character set selection WE8DEC

Default drive for Oracle directories D

Location of SAP database-specific files D

Location of Oracle data files D

Location of log files E, D

Location of mirrored database log files D,E

RAM for the SAP System 128

Location of CDs(during the installation) E:\Export1....E:\Export4

Enter the password for the SAP System administrator Sapcyii

Enter the password for the SAP System service user Sapcyii

Port number 3600

LDAP support No LDAP

Number of processes 4

43
Enter the password for the SAP database user sapr3 Sapcyii

Llegará un momento en la instalación, después de haber creado la base de datos

completa (suceso que tarda muchas horas en completarse), en que el instalador nos dirá

si queremos instalar otro idioma que no es Inglés o Alemán y nos referirá a unas notas

SAP.

En el implementación tenemos que instalar el idioma ruso, y es por eso que este momento

de la instalación es muy importante porque, tal y como dice el instalador, tenemos que

introducir unos parámetros en la base de datos.

Nota:

Para conectarnos a la base de datos, desde línea de comandos

escribimos svrmgrl y nos logamos como sapr3/Sapcyii , pues si no no podremos

ver ni modificar las tablas

Así, tenemos que insertar en la tabla TCPDB una línea que contenga 1500, 1500

para indicarle así que instale el code page del Ruso y una que contenga 1100, 1100 para

el codepage de Inglés. En líneas generales tenemos que seguir los pasos de

modificación y comprobación de tablas que indica la nota SAP 10935

Ejecución:

- Desde línea de comandos escribimos svrmgrl y damos enter

- Escribimos connect sapr3/Sapcyii

- Ahora hacemos select * from TCPDB; para ver que no hay ningún

registro en la tabla

- Insertamos el 1500 y el 1100 así: insert into table TCPDB values

(1500, 1500); insert into table TCPDB values (1100, 1100);

Una vez hecho esto la instalación puede continuar.

Nota:

Si tras el punto del lenguaje, la instalación diera un error de RFC, la

44
detenemos, paramos la instancia, la levantamos de nuevo y volvemos a lanzar la

instalación (ver punto siguiente para explicación detallada)

TRAS LA INSTALACIÓN

Arranque y Parada del Sistema SAP

La parada y el arranque de una instancia de R/3 se realiza con la herramienta

SAP Management Console.

Esta consola es muy útil porque nos va a decir todos los fallos que pueda tener el

sistema, desde errores de ABAP hasta que se nos estén quedando sin espacio los

tablespaces así como el grado de rendimiento que tiene la base de datos, los warnings de

optimización del sistema, errores en tablas, información sobre procesos, las colas de

trabajo de los diferentes procesos del sistema....

La herramienta va a guardar todos los ABAP bumps y terminaciones incorrectas

sufridas por el sistema. Así pues, va a registrar:

- Las caídas de los procesos al bajar la instancia (todos como warnings más un

error de conexión del Dispatcher)

- Si la tabla TCPDB no tiene entradas (si dice esto es porque no hemos realizado

el paso de la instalación de modificar la tabla)

- Información sobre cosas variadas

Además, en Open Alerts va a registrar todas las alertas y warnings del sistema con

respecto a :

- Bajos niveles de respuesta del Frontend

- Low performance de paginación, buffers, etc (estos errores no significan que la

instancia no funcione, pero en un sistema real con máquinas potentes no

deberían darse)

En Oracle, habrá alertas de performance, así como un error que dirá “Wrong

Subtipe”, y muchas veces veremos que los Tablespaces están de color amarillo

45
(esto conviene chequearlo, pues nos va a indicar si tenemos o no que aumentarles

el tamaño a los tablespaces)

Colores :

- Verde: Arrancado y funcionando perfectamente

- Amarillo: Arrancado, funcionando y con algún warning

- Rojo: Arrancado, funcionando y con errores

- Gris: Parado

Si queremos saber más sobre cada uno de los iconos, los desplegamos (con lo cual

saldrán a la derecha) y pinchamos con el botón derecho encima, indicándole Show All

Alerts.

El Syslog es una herramienta muy útil para saber lo que pasa en el sistema, y

funciona de la misma manera que el syslog de Windows. Es recomendable mirarla de

vez en cuando

Los iconos grises y los de

Información nos indican

eventos que han sucedido

que no son problemas.

Los iconos amarillos son

problemas sucedidos que no

no implican mal

funcionamiento

Los iconos rojos son errores

del sistema, y tenemos que

tenerlos muy en cuenta. Sin

embargo, no debemos preocuparnos por todos. Por ejemplo, la mayoría de los de

la imagen son errores de comunicación de haberse caído la red o haber bajado la

46
instancia con frontends abiertos

_ Siempre y cuando BMP y Servidor estén verdes se podrá entrar al sistema sin

problemas, estén como estén los otros, ya que el cambio de color de estos dos sólo

puede deberse al correcto o incorrecto funcionamiento del Process List.

Para poder arrancar y parar la instancia es necesario estar conectado en el sistema

operativo con el usuario que hemos utilizado para instalar (Administrator) o con el

usuario administrador que se crea durante la instalación, en nuestro caso, bpmadm.

Nota:

Para poder parar o arrancar la base de datos es imperativo ser bpmadm

Para arrancar una instancia de R/3 comprobamos que los servicios de SAP y

Oracle del sistema están funcionando. Tras esto, arrancamos la base de datos (con

privilegios de internal) y después la instancia de SAP

Ejecución de arrancar la base de datos:

- Desde línea de comandos invocamos svrmgrl

- Escribimos connect internal

- Escribimos startup open

Para parar la instancia primero pararemos la instancia SAP y después

desmontaremos la base de datos.

Ejecución de parar la base de datos:

- Desde línea de comandos invocamos svrmgrl

- Escribimos connect internal

- Escribimos shutdown immediate

Nota:

Hacerlo al revés podría causar inconsistencias en la base de datos, y lo

mismo sucederá si reiniciamos la máquina sin haber detenido antes las instancias

47
Entrando en el Sistema SAP

Para logar al sistema SAP es necesario tener instalado el SAPGUI y haber

arrancado tanto la base de datos como la instancia.

El SAPGUI es la aplicación, el frontend que nos va a permitir comunicarnos con

la aplicación. Es un entorno gráfico de ventanas.

Para instalarlo buscaremos en el paquete de software de SAP el cd de SAPGUI de

Windows y lo instalaremos como cualquier aplicación de Windows.

Cuando nos pida qué es lo que queremos instalar, le diremos el SAPGUI.

Al terminar veremos que tenemos un nuevo icono

en el escritorio llamado Sap Logon. Hacemos doble clic

en él y nos aparecerá una ventana como la de la imagen.

Pinchamos en Nuevo y nos aparecerá la siguiente

ventana

En Descripción escribimos SAP R/3, en Application Server escribimos Servidor

o ponemos la IP. SAP System es R/3 y System Number es el 00.

Aparecerá ahora una entrada en la primera pantalla, la pulsamos dos veces y

vemos que comienza a cargar. Apareceremos en la pantalla de Logon

- Client: Mandante, dejamos el 000

- User: Usuario, entramos como SAP* o

DDIC

- Password: la de SAP* es 06071992 y

la de DDIC es 19920706

Nota:

Las passwords son el día en que

empezó a funcionar SAP R/3, 6-7-1992

Nos pedirá que cambiemos el password, y así lo haremos, poniéndoles a los dos.

48
ANEXO I : Básico

Una transacción es un conjunto de pantallas más las órdenes que damos más los

programas que se utilizan en ellas. Para entrar en cualquier transacción podemos hacerlo

navegando por el Menú SAP (que aparece tras logarnos y al que podemos volver

pulsando varias veces sobre el botón Principio Transacción) o podemos hacerlo

escribiendo el nombre en el Cuadro de Transacciones y pulsando enter.

Si queremos saber el nombre de alguna

transacción para no tener que volver a recorrer

todo el árbol del menú pinchamos donde indica la

figura y nos aparecerá un cuadro desplegable que

nos muestra el nombre de la instancia y el

número, el mandante al que nos hemos conectado,

con qué usuario, qué programa de ABAP está

corriendo, el nombre de la transacción con que hemos llamado a ese programa y el

tiempo de respuesta

Si estamos dentro de una transacción y queremos pasar a otra directamente,

tendremos que poner /n<nombretransacción>

Ejemplo: /nstms /nrz10

Si estamos en una transacción y queremos que nos abra otra transacción en una

sesión distinta, tendremos que poner /o<nombretransacción>

Ejemplo: /ostms /orz10

Las transacciones son bastante complejas internamente en cuanto a navegación se

refiere, pero tienen forma arborescente. Por ejemplo, la stms

Si desde queremos ir a STMS, daremos al

botón

Si en cambio, queremos ir hasta cualquiera de

49
las otras, daremos al botón

Si queremos cancelar lo que estábamos

haciendo en cualquier transacción, daremos al

botón

Y si la transacción lo requiere y lo permite,

grabaremos los datos dando al botón

Una sesión es una ventana completa del SAPGUI donde nos hemos logado y donde

podemos trabajar, y podemos tener más de una a la vez.

Para abrir una sesión, desde cualquier transacción vamos al menú System/ Create

session. Para cerrarla, haremos como en cualquier ventana de Windows

Por norma, lo que vayamos a usar dentro de la implementación estará en el árbol del SAP East

Access en Tools _ Administration

ANEXO: CONFIGURACIÓN SEGÚN EL IMPLEMENTACIÓN

Address Manteinance

Logados en el sistema como SAP* y en el mandante 000, si intentamos hacer

cualquier transacción importante (como la stms) nos va a pedir que realicemos Adress

Manteinance. Lo que nos está pidiendo el sistema es que introduzcamos una serie de

parámetros

En la transacción

sucomp escribimos un

nombre y pinchamos en

crear. Le vamos a dar un

nombre a quien pertenece,

país y zona horaria y

guardamos.

50
Perfiles de instancia y Modos de Operación

Una vez que ya tenemos configurado el sistema principal vamos a modificar el

perfil de la instancia yendo a la transacción rz10

Un perfil de la instancia es un fichero que incluye cierta información sobre la

misma, como puede ser el idioma y mandante que aparecen por defecto al logar, el

directorio por defecto de los transportes...

Una instancia puede tener varios perfiles según la necesidad del momento. Por

defecto tiene dos, el perfil principal y el perfil de arranque.

Primero importaremos los perfiles –que están en local- yéndonos a

_ Utilities / Import profiles / Of active servers

Una vez importados en el sistema, seleccionaremos el perfil de la instancia, que se

llama BPM_DVEBMGS00_SERVIDOR, y elegiremos Extended Manteinance y

pincharemos en Change

Nos aparecerán entonces los parámetros que contiene la instancia, como por

ejemplo SAPSYSTEMNAME=BPM, SAPSYSTEM=00.....

El parámetro DIR_TRANS deberá tener la ruta \\servidor\saploc2\implementación

asignada, y será la ruta que tomarán todos los sistemas de transporte que creemos a

partir de ahora

Nota:

Tras darle el nombre al nuevo parámetro y su valor, damos al botón Copy

dos veces y vamos a la pantalla anterior, la que aparece en la figura de arriba. Allí

también daremos a Copy y marcharemos a la pantalla anterior, donde ya le

daremos al botón de guardar. El sistema nos dirá entonces que ha guardado el

perfil y que lo ha activado, y que es necesario reiniciar la instancia para que surta

efecto, cosa que haremos.

Nos pide el implementación además que la password de usuario sea como mínimo de 7 letras

51
y que cada 10 días debe ser cambiada. Para ello, introduciremos también los siguientes

parámetros

_ login/min_password_lng con valor 7 _ login/password_expiration_time con valor 10

Ahora que ya tenemos el perfil de la instancia cargado y con el sistema de

transportes en su sitio, vamos a crear un nuevo modo de operación en la transacción

rz04.

Un modo de operación es decirle a SAP para cada perfil de instancia que tengamos

creado, qué cantidad de procesos batch, de diálogo, etc, va a tener.

Pinchamos en Instances/Profiles y vemos que está vacío. Eso es porque no le

hemos dicho aún ningún modo de operación

Vamos al menú Profile/ Create new instance

Nos va a pedir una serie de parámetros, que son

Host name: Servidor

Sap System Number: 00

Start profile name: START_DVEBMGS00_SERVIDOR

Profile name: BPM_DVEBMGS00_SERVIDOR

Y le damos a guardar. Nos pedirá que modifiquemos el número de procesos que

tenemos. En total no puede haber más de ocho.

Según leí en una nota, para hacer los imports de los lenguajes era aconsejable tener

más de un proceso en background, de modo que le quitamos un proceso de diálogo y le

añadimos uno a batch

Volvemos a guardar y continuamos con la parametrización

Nota:

Si tenemos que cambiar un perfil de instancia que está configurado como modo de

operación, cuando queramos aplicar los cambios el sistema nos dará un warning sobre

que los modos de operación pueden quedar inconsistentes si aplica los cambios que le

52
hemos solicitado.

En el implementación, puesto que los cambios que vamos a realizar a partir de ahora no

influyen en los modos de operación, siempre que aparezca el warning que nos

preguntará si queremos chequear la consistencia le diremos que sí y veremos que todo

anda bien

Sistema de Transportes

Después de haber modificado el perfil de la instancia vamos a la transacción stms,

que es la del Sistema de Transportes.

El Sistema de Transportes es una herramienta fundamental, puesto que es la que

nos va a permitir importar y exportar objetos en nuestro sistema SAP. En una

instalación SAP de tres entornos (productivo, test y desarrollo), el Sistema de

Transportes nos permitiría llevar de un entorno a otro roles, usuarios, mandantes,

idiomas....

Pero también es importante en una instalación como la del la implementación, puesto que es

necesario para importar nuevos idiomas, support packages, documentos, roles, usuarios,

etc de fuera hacia nuestro R/3 y también entre mandantes

Digamos que, entre otras, su función es la forma de tener el sistema actualizado y al

día en todos sus entornos y mandantes

La transacción stms nos pedirá por defecto un nombre para el Sistema de

Transportes, que será, “Entorno Transportes instancia”, y su identificador será BPM.

Pinchamos en el icono de System Overview, y podremos ver los sistemas de

transportes que tenemos creados, en este momento, BPM.

Además de este, crearemos un sistema de transportes virtual de identificador VIR

desde el menú SAP System/Create/Virtual System

Desde el menú Extras, pincharemos en Generate RFC destinations (para

asegurarnos de que realmente las conexiones se han realizado, pues cada sistema de

53
transporte tiene que tener la suya) , y después en Distribute and activate configuration.

Esta acción es muy importante sobre todo cuando tenemos más de una instancia, ya que

todas conocerán así los cambios realizados en un sistema de transportes al que están

conectadas.

Ahora que tenemos creados los dos sistemas de transportes tenemos que configurar

las rutas. En caso de tener más servidores o más instancias, sería imprescindible que nos

hiciéramos un pequeño ‘mapa’ de cómo van a ir entrelazados.

Desde la primera pantalla de la transacción

stms, pinchamos en transport routes. Una vez

estemos allí, pinchamos en el botón Display _

Change (o F5), ponemos cada uno de los sistemas de

transporte en la parte media de la pantalla y

pinchamos en Check. Una vez nos diga que todo

está bien, grabamos.

De momento, la configuración será temporal, pues luego tendremos que volver a

modificar el Sistema de Transportes para adecuarlo a las necesidades del implementación

Instalación de lenguajes

La implementación nos pide que instalemos lenguajes. Los lenguajes en la release 4.6C de R/3

se importan de los cds de support packages que vienen incluidos en la caja de SAP y se

van a instalar en el sistema a través de transportes, y es por eso que hemos configurado

primero el Sistema de Transportes.

(Para esta fase de la post instalación estamos usando las SAP Notes 42305, 103687,

10935, 73606, 39763, 23955, 309497 y el documento pdf llamado Language Transport

(BC-CTS-LAN) -que podemos encontrar en el cdrom 1 de los paquetes de lenguajes-.

Hay que buscarlos en la SAPnet, imprimirlos y leerlos)

Por defecto, SAP instala tanto el Inglés como el Alemán. Estos lenguajes utilizan

54
un code page específico que es el ISO8859-1 y son los dos idiomas en que la aplicación

está completamente traducida, y es por eso por lo que se usan para hacer las

suplementaciones a los otros lenguajes.

Además, en caso de tener que instalar Support Packages en el entorno SAP

deberíamos instalarlos después de haber importado el idioma, puesto que los Support

Packages sólo se van a traducir en los lenguajes que tengamos instalados en el sistema

Un code page es una lista de caracteres –letras, números, signos...-, y soportan una

serie de idiomas que comparten esos caracteres. El ISO8859-1 es un Single Code Page,

lo cual significa que sólo podremos instalar aquellos idiomas que tengan caracteres

similares al Inglés o Alemán.

A través de este code page vamos a instalar el Español tal y como nos lo piden,

pero no podemos instalar el Ruso porque no está soportado. Es por este motivo por el

que en la instalación hemos mantenido la tabla TCPDB, pues es en ella donde SAP

reconoce los codepages que tiene instalados. Así, si desde el svrmgrl de Oracle (desde

línea de comandos) hacemos un select * de TCPDB, veremos que tiene una entrada, la

1500, 1500 que se la hemos añadido en la instalación.

Nota:

Siempre que queramos hacer cambios o ver objetos de la base de datos

tendremos que ser el usuario sapr3 (el que nos pide durante la instalación) porque

él es el dueño de todos los objetos.

El codepage (1100, 1100) que se instala por defecto con el Inglés y Alemán, no

aparece en esta tabla por defecto en una instalación normal, de modo que habría que

mantener la TCPDB para que sí apareciera (Es común que, si instalamos y no queremos

tener un codepage distinto al 1100, el Syslog de SAP nos avise de que la tabla TCPDB

no tiene entradas).

55
Mantenimiento de tablas

Antes de instalar cualquier idioma tenemos que asegurarnos de que las tablas

referentes a los idiomas están mantenidas.

Desde el svrmgrl de Oracle, conectados como sapr3, miramos en la tabla TCP0C

que existe una entrada que contiene los locales que necesitamos (para instalar los

idiomas previamente hemos leído todas las notas arriba comentadas y hemos instalado

en Windows y puesto activo el idioma Ruso, además de haber instalado fuentes cirílicas

tal y como indican las notas) y su codepage, pues de no ser así tendremos que

modificarla.

Y miramos que, efectivamente, la tabla TCPDB contiene las dos entradas

pertinentes, 1500 y 1100

Vamos a la transacción se38, que es el

lanzador de programas (reports) ABAP y

corremos el report RSCPINST. Para ello,

escribimos su nombre y pinchamos en el

botón resaltado en la figura

Nota:

ABAP es el lenguaje de programación de SAP, en el que está escrita toda la

plataforma y el que usan los desarrolladores para crear transacciones para el

cliente

En el Step1

seleccionamos el Inglés y en

el Step2 seleccionamos

Latin1 or MDMP.

El MDMP es la opción

que tendremos que

56
seleccionar también con el

Ruso, pues es la que permite

tener más de un codepage

instalado en el sistema.

Ahora pinchamos en

simulate y, si todo va bien,

volveremos a la pantalla

anterior y lo activaremos. Esto mismo tendremos que hacerlo cuando tengamos

instalados los otros idiomas.

Una vez que tenemos mantenido el sistema hasta este punto, es conveniente que

aumentemos el tamaño de ciertos tablespaces en Oracle que estarán bastante escasos de

espacio. Para comprobar que, efectivamente se están quedando sin espacio, podemos

mirarlo en el SAP Management Console, en Open Alerts / Oracle

Cómo aumentar el tamaño de los tablespaces

Desde línea de comandos invocamos al sapdba, que es un programa que nos va a

permitir gestionar ciertos asuntos de la base de datos.

- Elegimos la opción de tablespaces

- Elegimos la opción c de ver cuán ocupadas están. Sapdba nos dirá cuáles son las

que están más llenas y que tenemos que aumentar sin demora, aunque es aconsejable

aumentar todos los tablespaces que sobrepasen el 85% de su capacidad

- Elegimos un tablespace y le damos a la f. Luego, si tenemos en disco el espacio

que necesita, damos a la s y que comience

-Al terminar nos recomendará hacer backup, pero le daremos a la q, luego a la y

-Repetimos todo el proceso con todas las tablespaces necesarias

Import de los lenguajes

Vamos a la transacción stlm, y seguimos los

57
pasos que nos indica el pdf Languaje Transport

(BC-CTS-LAN) de cómo usar esta transacción.

-Pinchamos en Classify Languaje

-Elegimos Ruso o Español, y suplementación

con Inglés y grabamos

-En la nueva carpeta de idioma que hemos

creado, pinchamos en Import Package.

Nos pedirá una ruta (que será la unidad de cdrom),

y pinchamos en Find Packages. Encontrará

uno. Lo seleccionamos y pinchamos en Execute

Nota:

Cuando se hayan terminado de importar los lenguajes, tendremos que

suplementar el Español como pide el implementación

Importaremos primero un lenguaje y cuando termine el otro, por dos motivos. El

primero porque los dos import irían en paralelo, podríamos quedarnos sin procesos

batch suficientes y el servidor no es tan potente como para hacer tanto a la vez, y el

segundo porque hay que tener en cuenta el tamaño de los tablespaces.

Nota:

El import de un lenguaje tardará varias horas, y sabremos que está

importando el lenguaje porque si vemos dentro de la carpeta del lenguaje y dentro

de Imported Packages, vamos a ver un camioncito rojo delante del nombre del

paquete que está subiendo. Además, podemos comprobar los logs de los

transportes que va realizando así como el log del job

Así, al terminar de importar el primer lenguaje vamos a comprobar los tablespaces

y veremos que efectivamente, tenemos que aumentar de nuevo algunos de tamaño. Lo

hacemos según se explicó más arriba, y continuamos importando el siguiente lenguaje

58
Por fin, cuando hemos

terminado de importar los lenguajes

modificamos el perfil de la

instancia de nuevo en la transacción

rz10.

Vamos a añadirle un parámetro

nuevo llamado

zcsa/installed_languages con el

valor DESR, de modo que sepa que

tenemos instalado D(Alemán), S(Español) R(Ruso) y E(Inglés) . Este parámetro es

imprescindible puesto que si no lo escribiéramos no podríamos loguear en el sistema

con nuestros recién instalados idiomas

Y vamos a cambiar el parámetro zsca/system_language y ponerle una S para que

tome el Español como idioma por defecto

Reiniciamos la instancia después de grabar el perfil y activarlo

Seguido a esto, volvemos a correr

el report RSCPINST como hicimos

anteriormente y vemos que ahora

aparecen todos los idiomas que

añadimos en el perfil de la instancia

Todos ellos tienen que funcionar

con MDMP para que nos permita tener

usuarios que logueen en Español,

Inglés o Aleman y por otro lado, los

que usan Ruso y probamos a logar con

el Español y el Ruso

59
Nota:

Para loguear en Ruso debemos modificar un parámetro en el SAPGUI, y

decirle que tome el codepage 1500 en vez del 1100 por defecto

Suplementación del Español

Hecho esto, vamos a proceder a suplementar el Español. Según la nota 309497,

podemos tener problemas a la hora de suplementar que pueden ser resueltos aplicando

el support package de Basis SAPB46C03.

Comprobamos que existe en el sistema, así que corremos la transacción spam

Elegimos la opción Applied Support Packages y pinchamos en Display, y nos

aparecerá una lista de todos los que están instalados en el sistema. Buscando entre los

paquetes de Basis veremos que el que buscamos aparece como instalado

O, si pinchamos en Package Level, nos aparecerá esta otra pantalla que nos indicará

qué nivel de parche tiene Basis, que es del que necesitamos el 3. Como vemos que tiene

el 15, no es necesario instalar nada

En la transacción smlt, pinchamos en Español y

hacemos doble clic sobre Supplementation with English,

carpeta que nos creó cuando creamos la clave Español

antes de importar.

Nos aparecerá una pantalla donde elegiremos qué

tablas vamos a suplementar.

Le damos una descripción y pinchamos en Select, y veremos que nos han aparecido

abajo una serie de tablas. Ahora, elegimos las tablas que queremos (que van a ser todas)

pinchando en el botón Select All

Por último, pinchamos en el botón Execute.

El proceso durará una hora aproximadamente, y podremos ver lo que hace del

mismo modo que mirábamos el import del lenguaje

60
Cuando termine tendrá un triángulo amarillo, que es porque no todas las tablas se

han suplementado.

Nota:

Es conveniente volver a mirar el tamaño de los tablespaces después de

ejecutar la suplementación y agrandarlos si fuera necesario

Creación de los mandantes

Una vez terminada la parte de lenguaje procedemos a crear los mandantes en la

transacción scc4.

Una de las cosas más importantes que debemos tener en cuenta en un sistema SAP

es que los tres mandantes por defecto nunca podrán ser productivos ni podrá acceder a

ellos nadie que no sea el administrador

El mandante 000 es el mandante de ‘seguridad’. En el mandante 000 vamos a

configurar las cosas esenciales y básicas de toda la instancia de modo que todos los

mandantes que creemos serán copias suyas. Por esa razón no hemos copiado el

mandante 000 al principio, sino una vez tenemos hechas ciertas parametrizaciones como

el idioma, ya que tiene que ser común para todos los mandantes

El mandante 000, y va a servirnos, entre otras cosas, para comprobar entre

mandantes qué es lo que hemos podido cambiar respecto al él en nuestra instancia y

poder detectar así posibles fallos

El mandante 001 es una copia del mandante 000, y por eso no hay que modificarlo

pues, en caso de pérdida del sistema y del mandante 000 siempre lo tendríamos como al

principio

El mandante 066 es el mandante que utiliza SAP para realizar las auditorías. Dos

veces al año entran al sistema y lo chequean para ver si está bien, aunque si tenemos

problemas podemos pedirles ayuda y entrarán por él también. Este mandante tampoco

lo podemos tocar puesto que, si hacemos algo y luego SAP no puede conectarse ellos no

61
asumen la responsabilidad

Hacemos clic en ver-modificar y pinchamos en el botón New Entries. Nos

aparecerá una nueva ventana con campos que rellenar, de los cuales solo necesitamos

Client: (Número de mandante) 007, (Descripción) Gold

Client Role: (De qué va a ser el cliente) Test

Changes and transports for client-specific objects: Automatic recording of

changes

Y el resto lo dejamos en blanco, o por defecto

Guardamos los cambios y, en la ventana anterior veremos que ahora aparece el

cliente que hemos creado

Una vez tenemos creada la entrada para el nuevo mandante tenemos hacer logon

en el nuevo mandante que hemos creado, en nuestro caso, el 007, con el usuario SAP* y

la contraseña pass

Nota:

En todos los mandantes que copiemos, la contraseña de SAP* y de DDIC

va a ser pass hasta que la cambiemos

Antes de copiar nada tenemos que ver si tenemos espacio suficiente en los

tablespaces PSAPPOOLD, PSAPPOLI, PSAPSTABD y PSAPSTABI, pues son los que

van a soportar la carga de la copia. Por eso, es muy posible que tras cada copia de

mandante haya que aumentar el tamaño de los tablespaces

Nota:

Si no tenemos muy claro lo que va a ocupar la copia de mandante, es

recomendable tener una ventana con el sapdba abierta e ir comprobando

periódicamente el crecimiento de los tablespaces, agrandándolos cuando fuese

necesario

Una vez comprobados los tamaños y estando dentro del nuevo cliente vamos a la

62
transacción sccl (transacción para copiar mandantes) y rellenamos los campos como en

la figura

y vemos que podemos indicarle que comience el trabajo inmediatamente o que lo deje

como un proceso en background. Vamos a decirle que comience inmediatamente

Las copias de mandante suelen tardar un rato en estar terminadas, sobre todo

dependiendo de la cantidad de datos que tengan que ser copiados

Nota:

Este proceso que hemos comentado para crear el mandante 007 vamos a

tener que realizarlo con cada uno de los mandantes que nos pida el implementación

Cuando tengamos copiados todos los mandantes, volvemos a la transacción scc4

para cambiar los parámetros necesarios

Por fin, como se pide que el mandante por defecto sea el 007, en el perfil de la

instancia (transacción rz10) añadiremos el parámetro login/system_client con valor

013

Creación del Sistema de Transportes del Implementación

A continuación y a petición de la implementación, crearemos los dos Sistemas de Transporte

virtuales ACC y COR en la transacción stms

Pinchamos en el icono de System Overview, y podremos ver los sistemas de

transportes que tenemos creados, en este momento, BPM y VIR

Desde System Overview borramos el sistema de transportes virtual que teníamos en

un principio (VIR), porque no nos es ya de utilidad.

Para ello seleccionamos el sistema de transporte, y vamos al menú SAP

System/Delete

Desde el menú SAP System/Create/Virtual System crearemos los dos nuevos

sistemas de transporte virtuales de identificador ACC y COR.

Tras crearlos, no debemos olvidar que, desde el menú Extras, hemos de pinchar en

63
Generate RFC destinations y después en Distribute and activate configuration.

Desde la principal de stms, pinchamos en el botón de Transport Routes nos van a

aparecer los tres sistemas de transporte que tenemos creados pero sin rutas de

transporte.

Pinchamos en el botón Display _ Change (lapiz y gafas) y vamos al menú

Configuration/Standart Configuration/ Three systems in a group.

En la ventana que nos aparece, vamos a seleccionar

- Para Desarrollo, el entorno BMP

- Para Quality, el entorno ACC

- Para Productivo, el entorno COR

Le damos a grabar, y veremos que nos aparecen los tres entornos con sus rutas de

transporte configuradas.

Ahora creamos el transport group.

Vamos al menú Edit/Transport Target Group/Create.

Le damos un nombre al nuevo grupo,

por ejemplo /QUAS/

Nota:

Los nombres de grupo tienen que

estar entre /

Agregamos en Target System al sistema

ACC como nos han pedido en el implementación, y

pinchamos en el botón Client assignment.

Entonces agregamos el mandante 020 y por

fin damos a guardar

Las rutas de transporte aparecerán así

Damos al botón de check, al de distribuir configuración y guardamos.

64
¿Qué ocurre si cambiamos el SID de la rz10?

Dejaría de funcionar. El SAPGUI no sabría dónde conectarse, como todas las

conexiones RFC. El SID + el system number de una instancia de SAP son como su

‘carnet de identidad’, si cambiamos una parte.

Si hablamos del SID de la instancia de base de datos, SAP no podría conectar a la

base de datos porque no la encontraría, de modo que también dejaría de funcionar

Troubleshooting

Durante la Instalación

En el grupo de programas creado por el instalador del R3SETUP hay además de

las diversas instalaciones un programa llamado Command File Editor, R3SEdit que

nos va a permitir, si nos hemos equivocado al insertar algún parámetro en la

instalación, volver a ese paso. Para utilizarlo:

- Lo lanzamos

- Cargamos el fichero CENTRDB.R3S

- Veremos que aparece una lista de nombres y una casilla marcable. Los

nombres con tic son los que ya han sido introducidos por el usuario, así que lo

que hay que hacer es desmarcar la casilla en que nos hemos equivocado

Fallos en RFC destination. Este error parece ser común en las instalaciones de

R/3, y se solventa deteniendo la instalación, parando y arrancando la instancia de SAP

manualmente. Luego podremos continuar con la instalación lanzando de nuevo el

R3SETUP

Alertas desde el SAP Management Console

Problema: Da un error en la tabla TCPDB pues dice que no tiene entradas.

Deberíamos haber mantenido esta tabla durante la instalación, pues ahora será

más complicado instalar el ruso.

Recomendación: Intentar entrar los campos señalados durante la instalación con

65
sql e intentar instalar el ruso. Si no funcionara, reinstalar.

Problema: BPM y Servidor están amarillos en vez de verdes

Comprueba el estado del Process List. Seguramente sea culpa del Dispatcher.

Dale tiempo, al arrancar la instancia suele tardar en conectar.

Problema: Da un error en la tabla TCP0D pues dice que tiene dos entradas

Esta tabla sólo tiene que tener una entrada, que es ( , E). Si tiene más, es

conveniente retirarlas

SAPGUI

Problema: Aparece un error de conexión

Comprueba que el equipo está enchufado a la red, y que la red funciona.

Comprueba también el estado del Dispatcher en el Sap Management Console.

ABAP Short Dumps

Se pueden deber a varios motivos, pero si no aparece la pantalla de SAP Easy

Access y no nos deja entrar en transacciones como SMLT o STMS, desinstalar del

sistema el SAPGUI completamente y reinstalarlo

Problemas importando lenguajes

Problema: Estamos importando un lenguaje y el log de transportes no ha

cambiado en varias horas.

Comprobar todo el sistema de transportes. Comprobar que hemos creado un modo

de operación y que tenemos dos procesos background funcionando

Problema: Estábamos importando un lenguaje y el servidor se ha caído o hemos

parado la instancia

Si todo está bien, al reiniciar la instancia de SAP el job que controla el importe del

lenguaje se habrá reactivado. En cualquier caso, si no se hubiera reiniciado el job y

hubiera un rayo en lugar del camioncito, pinchamos en el botón que son unos pasos

para reiniciar el job

66
Problema: No se puede hacer display de las tablas TCPDB, TCP0C, TCP0D

Hay que mantenerlas primero desde la transacción se38 y corriendo los reports

RSCPINST, RSCP0004, RSCP0017.

Se pueden ver, si no, desde el sqlplus o svrmgrl haciendo Select * from TCPDB;

Problema: Probando la configuración del Ruso en el report RSCPINST, dice que

no está el local Russian_Russia*.nls

Comprueba si está instalado el idioma Ruso en el Win2000 del servidor. Si no

está, instálalo

Si está instalado, comprueba que en el perfil de la instancia has añadido una R al

parámetro zsca/installed_languages

67
CAPITULO DOS

Objetivo

En este capitulo nos llevara de la mano a entender de como funciona la seguridad de SAP a si como
se establecen los principios y normas a seguir en la , administración y control.

El objetivo principal o, es tener plenamente identificados los factores que influyen en el

mantenimiento de la seguridad, así como las actividades que debe de realizar el encargado de la
seguridad SAP

ARQUITECTURA

Figura 1

68
COMO FUNCIONA LOS MANDANTES

Ya vimos que básicamente pueden existir tres ambientes (Desarrollo, Calidad, y Producción) y para
que servían cada uno de los mismos. Ahora podemos explicarlo mas a detalle.

Los ambientes mencionamos que normalmente están ubicados en equipos

(computadoras/servidores) distintos, cada ambiente en su respectivo servidor (generalizo para
simplificar), el hecho es que cada ambiente, o sistema puede a su vez contener otras divisiones
dentro de si mismo.

A modo de ejemplo, un ambiente de desarrollo, puede contener una subdivisión que sea la que va a
poseer las parametrizaciones propiamente dichas, otra que haga las veces de ambiente de pruebas
unitarias (para que los mismos desarrolladores o parametrizadores prueben el funcionamiento de lo
que definen).

Estas subdivisiones se llaman Mandantes en SAP

Mandantes

Los mandantes poseen nombres numéricos, siendo a modo de ejemplo un ambiente de SAP de
nombre DEV (por Development), y mandante 200, otro mandante en el mismo equipo puede
ser UNI(por Pruebas Unitarias) y mandante 210. Otro ambiente puede serQAS y el número de
mandante el 300, y el ambiente productivoPRD y mandante 400.

Los mandantes poseen maestros de usuario distintos, esto quiere decir que en un mismo sistema
(DEV) un usuario puede tener acceso al mandante200 pero no al 210, o puede acceder a los dos pero
con distintos permisos.

La información operativa que se cargue en un mandante no es compartida con el otro, a pesar de

que la información por pertenecer a un mismo sistema, se aloja en una misma base de datos. Las
tablas con las que trabaja SAP poseen normalmente un indicador de mandante, por lo
que SAP siempre lee este campo primero y solo muestra la información del mandante en el cual el
usuario se autenticó.

SEGURIDAD EN MANDANTES

Un tema sumamente importante los distintos 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.

69
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.

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)

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)

Protección contra copias de mandante:

- 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)

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 posibilidad 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

70
AMBIENTES

¿Qué es un ambiente productivo?

Es el ambiente donde la empresa opera, y sobre el cual se realizan todas las operaciones diarias de
la organización, contiene toda la información sobre compras, pagos, cobranzas, contabilidad, etc y
al mismo acceden los usuarios de las áreas específicas (Depto de Contabilidad, Tesorería, RRHH,
etc)

¿Qué otros ambientes necesitamos?

Una empresa promedio se encuentra constantemente realizando mejoras sobre su software,
reparando errores, o en pos de implementar nuevas funcionalidades. Nos puede parecer correcto o
incorrecto, pero esto es así cuando se trabaja con grandes ERPs.

Para estar mas apegado a los estándares

Ambiente de desarrollo

donde acceden los parametrizadores (consultores de producto) y desarrolladores o

programadores que no posee información del trabajo diario de la organización.

Ambiente de Calidad

Al que acceden los consultores de producto, consultores funcionales, y usuarios para probar el
correcto funcionamiento del programa o funcionalidad configurada en el ambiente de desarrollo
pero sin alterar los datos del día a día de la organización, con datos de prueba no críticos o
censurados.

Ambiente de Producción

donde los consultores y desarrolladores no acceden, salvo en casos particulares y solo como
visualización, y es en donde la organización posee sus datos operativos y al que acceden todos los
usuarios finales del sistema.

Ambiente de Desarrollo
Aquí se realizan los desarrollos y parametrizaciones del sistema. Al realizar un nuevo desarrollo, se
genera una orden de transporte. Mediante la misma, el desarrollo pasará a los demás ambientes.

71
EL SISTEMA DE TRANSPORTES SAP

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 la migración 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.

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 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 para las funciones administrativas y, en lo referente a las autorizaciones
de crear, modificar y liberar órdenes y tareas.

72
En resumen

Este landscape es propio de un sistema SAP en producción (cuando ya opera para la empresa) en el
caso de las implementaciones en las que participan habitualmente los consultores el ambiente puede
solo contener el Ambiente de Desarrollo en una primera etapa, y posteriormente para la llegada de
las pruebas integrales suele incorporarse el Ambiente de Calidad, y finalmente cerca de la fecha de
implementación el Ambiente Productivo.

ESQUEMA DE SEGURIDAD

SAP es el ERP más popular en el mundo y suele sustentar el núcleo del negocio de muchas
empresas. Por eso garantizar su seguridad debe ser un objetivo prioritario para ellas.

Para cubrir por completo todas las capas lógicas que conforman la seguridad de un sistema SAP,
necesitamos tener en cuenta los siguientes procesos:

73
 Figura 2

1) Capa de negocio SAP: Auditoria de políticas de asignación de privilegios (usuarios, perfiles,

authorization objects).

2) Capa tecnológica SAP: Análisis de vulnerabilidades de los servicios SAP (saprouter, sap-
dispatcher, sap-gateway, sap-message-server, sap-igs, sap-portal) .

3) Base de Datos: Análisis de vulnerabilidades a nivel de BBDD.

4) Sistema Operativo: Análisis de vulnerabilidades a nivel de sistemas y redes.

Tradicionalmente la capa tecnológica de SAP ha sido la menos tenida en cuenta por la mayoría de
profesionales:

 Los consultores SAP, normalmente se limitaban a auditar solamente la seguridad de la capa

de negocio, ignorando la base tecnológica que toda gran aplicación tiene.
 Los auditores de seguridad, normalmente se limitaban a analizar la plataforma (sistema
operativo y base de datos) como si de una auditoria normal se tratase. Sin tener en cuenta la
gran complejidad que tiene un sistema SAP.

El problema es que una vulnerabilidad grave en cualquiera de las capas compromete completamente
la integridad del sistema SAP en su conjunto.

Por ejemplo si se produce un compromiso a nivel de sistema operativo, el atacante podría modificar
cualquiera de las capas superiores y conseguir acceso de administrador.

Si se compromete la base de datos. La configuración de seguridad del entorno SAP queda también
comprometida ya que se encuentra almacenada en ella.

Si la capa tecnológica no se encuentra protegida, cualquier usuario de la red podría llegar a

conseguir privilegios de administrador en el sistema SAP y tomar control del mismo.

Por lo tanto, es imprescindible que una auditoria de seguridad de un sistema SAP cubra los cuatro
niveles.

74
Seguridad en la aplicación SAP

Para la gente nueva en esta tecnología se debe de tener en cuenta las siguientes indicaciones para
tener un control de la seguridad mas robusto.

MEJORES PRÁCTICAS

Las mejores prácticas de seguridad nos indica que tenemos en tomar en cuenta estas
recomendaciones en cada uno de los sistemas que estemos administrando.

Seguridad en las cuentas

Usuarios, Grupos, Políticas de Contraseña, Asignación de correcta de permisos, Limitar el acceso a

los usuarios Administradores (solo vía consola).

Seguridad en el Sistema de Archivos

Utilizar particiones NTFS, Eliminar Shares por default, asignación de permisos correctos y no full
control, Archivos con SETUID y/o SETGID mascara de creación de archivos (Umask)

Seguridad en los Servicios

Desactivar todos aquellos servicios que no se utilicen (smtp, ntp, telnet, snmp, echo, rsh y rlogin).

Seguridad en Bases

 Cambiar todas las contraseñas de los usuarios creados por default.

 Eliminar contraseñas que se almacenan en texto plano después de la
 instalación.
 Instalar las últimas versiones de Service Pack y parches disponibles.
 Bloquear los accesos a los puertos de Sql para los clientes “no

75
  confiables”
 Aplicar los permisos correspondientes a los directorios donde se instala
 la base de datos.
 Restringir el acceso administrativo al Listener.

La Problemática de la Seguridad de SAP

En la mayoría de las implementaciones , las configuraciones de seguridad son dejadas por defecto.
Las configuraciones por defecto generalmente son inseguras.

Conclusión: Si bien SAP posee medidas de seguridad robustas, el problema está en la Seguridad de
las Implementaciones, que generalmente son por defecto!!! Seguridad en Sap es mucho más que
Roles y Perfiles.

Mecanismos de Autenticación

Usuario y contraseña, Secure Network Communications (SNC), Certificados de Cliente SSL

X.509, Logon Tickets, Pluggable Authentication Services (PAS)

Seguridad de los Usuarios

Usuarios por defecto ( SAP*, DDIC, EARLYWATCH), Desactivar SAP*, Bloquear

EARLYWATCH y DDIC, Cambiar las contraseña de estos usuarios en todos los mandantes.

Política de Contraseñas
Aplicar políticas de contraseñas como por ejemplo, Longitud de contraseña, caducidad de
contraseña, historial de contraseñas, lista de contraseñas no permitidas ( Tabla USR40)

Mecanismos de Autorización
Asignación de autorizaciones ( Objetos de autorización, Perfiles, Roles), SAP_All, autorizaciones
S_*.

Seguridad de las Interfaces

Restringir el acceso a la tabla RFCDES y a la transacción SM59. Habilitar SNC para conexiones
que transmitan información sensible. Evitar almacenar los passwords en las conexiones RFC.
Configurar los archivos secinfo y reginfo. Restringir el acceso al Gateway Monitor.

Mantener un esquema separado de ambientes de Producción, Calidad y Desarrollo. Establecer

controles de transportes a producción. Asignar roles y autorizaciones para los transportes.

76
Proporciona un nivel de seguridad optimo ya que al contar con ambientes separados se de
continuidad a las mejores practicas de la administración a nivel mundial.

POR QUE ANALIZAR LA SEGURIDAD DE SAP?

La mayoría de las empresas es el sistema mas importante ya que es uno de los que proporciona un
riesgo directo al negocio.

Como Analizar la seguridad SAP

Existen en el mercado muchas consultoras o auditores externos que realizan análisis y revisiones
anuales a estos sistemas llamados ERP’S en el caso de Grupo Financiero se cuenta con el apoyo de
Salles Thorton que es una de las empresas de auditoria mas confiables dentro del mercado. Pero
esto no es todo ya que cada empresa debe contar con una política de Seguridad para machear las
indicaciones mencionadas anterior mente. Ya que con una política de seguridad robusta se facilita la
administración y entendimiento de la seguridad de cualquier sistema ERP.

Dentro de todas las bondades ya mencionadas SAP también cuenta con algunas vulnerabilidades
controlables .

 Usuarios y contraseñas por defecto (SAP*, DDIC, EARLYWATCH, Oracle, Informix, SA,
Administrador, Root)
 Scripts para interfaces con usuarios y contraseñas.
 Relaciones de confianza entre equipos mal configurada.
 Permisos a nivel NFS o Share mal configurados.
 Errores de configuración en SAPRouter. Sin restricción de acceso.
 Publicación de Servicios de SAP en Internet mal configurados (SAPRouter, ITS, Business
Connector).

 Vulnerabilidades de Sistemas Operativos que soportan SAP

 Vulnerabilidades de Base de Datos que soportan SAP.
 Usuarios de desarrollo de SAP con privilegios amplios sobre sistemas de Producción.
 Usuarios de aplicación SAP con contraseñas triviales.
 Privilegios amplios para usuarios de SAP (asignación de transacciones criticas del sistema
,SAP_ALL)
 No aplicación de parches de Seguridad en SAP, permitiendo la explotación de
vulnerabilidades

El sistema operativo y la base de datos representan los pilares de los sistemas SAP. Los mismos
deben mantenerse actualizados y configurados en forma segura.

77
 SAP provee una gran cantidad de soluciones y una arquitectura compleja, la cual debe ser
asegurada a nivel aplicación y comunicación.

Es fundamental mantener un control estricto sobre los usuarios y las autorizaciones de los mismos
en el sistema. Por defecto, muchas configuraciones son inseguras y deben ser modificadas.

Este tipo de vulnerabilidades son controlables y se pueden erradicar haciendo una buena
mancuerna con el área de Base de Datos ya que estos son parámetros que solo una persona
certificada en el modulo de Basis puede configurar y será tarea del personal de Seguridad indicarle
los puntos débiles de la configuración de SAP .

Esto se logra con la transacción SE38 y ejecutando el reporte de parámetros principales de SAP
llamado RSPARAM con este reporte nos dara la información de configuración que cuenta SAP.

78
CONCLUSION

En el entorno SAP existen una serie de transacciones que deben ser limitadas, incluso impedir desde
cualquier usuario su llamada, debido a los riesgos de seguridad que implican. Principalmente se
trata de la SE11, SE16, SE30, SA38, SM30, SE16m y SM49, y debemos prestar especial atención a
RSBDCOS0, SM38 (shell de sistema), SM49 (creación de órdenes del sistema) y SM59 (ejecución
de órdenes en el sistema). Otro punto de control a tener en cuenta son aquellas transacciones
desarrolladas a medida para la empresa por un equipo de desarrollo no perteneciente a SAP y que,
por tanto, no han pasado por el equipo técnico de calidad de SAP.

Otro aspecto de seguridad en el ámbito de SAP es el relacionado con la gestión de usuarios; de

entrada, no se debe permitir a un usuario saltar a otro mandante distinto al asignado, para lo que
aquellos usuarios que se conecten de forma remota (ya sea mediante la interfaz Web o mediante el
cliente R/3) deben de estar configurados como usuarios de fondo y NO como diálogo.

De la misma forma, es recomendable la aplicación de políticas de seguridad que fuercen al uso de

contraseñas seguras, por ejemplo empleando la transacción SM30 → USR40 para especificar,
mediante expresiones regulares, qué contraseñas no son válidas y un diccionario de palabras no
permitidas. Adicionalmente, mediante el uso del report RSPARAM, se pueden parametrizar
aspectos como el número de logins incorrectos, longitud mínima de la contraseña, seguimiento de la
inactividad, etc.

Finalmente, pero no por ello menos importante, debemos hablar de una segregación de funciones
correcta en SAP, que no permita a un determinado usuario acceso a determinadas combinaciones de
transacciones; para ayudar en esta segregación de funciones, SAP dispone
del report RSVR008_009_NEW, que permite indicar las combinaciones críticas existentes en el
sistema.

79
BIBLIOGRAFIA

ELEMENTOS ESENCIALES DE SEGURIDAD DE SAP

Autores: Alfredo Hernandez Gabriel Gorostieta

Editorial: Equality Press

Diciembre ,2006

SAP Certified Technology Profecional – Security whith SAP Netweaver 7.0

Autores : SAP Academy.

Enero, 2010

METODOLOGIA O CHECKLIST PARA AUDITAR UN SISTEMA SAP

Autor Mariano Nuñez Di Croce

Junio , 2009

Seguridad SAP en profundidad, serie de artículos donde explican los pasos a seguir para revisar la
seguridad de un sistema SAP en profundidad.
Volume I: The risks of downwards compatibility
Volume II: SAP Knowledge Management – The risks of sharing
Guía de Seguridad para sistemas SAP NetWeaver pero también unas directrices para auditar SAP ECC
creado en el 2009

Fuentes

http://sap-school.com/certificationquestionsSecurity

http://www.mundosap.com

80
GLOSARIO

 GFI: Grupo Financiero Interacciones

 Confidencialidad: Característica de la información que garantiza que la información pueda
ser accedida solamente por quienes están específicamente autorizados para hacerlo.
 Disponibilidad: Característica de la información que garantiza que los usuarios autorizados
tengan acceso a la información en la forma, tiempo y lugar en que son requeridos por el
proceso del negocio.
 Información Crítica: Información cuya pérdida, destrucción o modificación en forma no
autorizada pueden impactar significativamente la capacidad de GFI para mantenerse como
negocio.
 Integridad: Propiedad de la información que garantiza que ésta sea modificada en forma
debida y sólo por partes autorizadas.
 Propietario de la información: Usuario que tiene la responsabilidad ante GFI de los datos
técnicos o del negocio con relación a la actividad que desempeña.
 Riesgo: El impacto de la materialización de una vulnerabilidad, considerándose ambos la
probabilidad y la frecuencia del evento fortuito o intencional a los activos de información de
GFI, el cual es negativo para el negocio.
 SGSI: Sistema de Gestión de Seguridad de la Información
 Seguridad de la Información: Preservación y protección de la confidencialidad, integridad
y disponibilidad de la información, para asegurar la continuidad del negocio, y minimizar
los riesgos a través del establecimiento, implementación, monitoreo, revisión y mejora de
controles, incluyendo políticas y procedimientos para asegurar que los objetivos de
seguridad y de negocio son alcanzados.
 ROL: Definición de actividades y transacciones permitidas para un usuario dentro del
sistema SAP
 Perfil: Definición de permisos y objetos que pueden ser visualizados, modificados,
adicionados, o reportados por las transacciones definidas en el ROL.
 Transacción: Módulo de operación que permite realizar una actividad específica dentro del
sistema.
 Core Bancario: Se define como el negocio desarrollado por una institución bancaria con
sus clientes minoristas y pequeñas empresas. Esto básicamente quiere decir que todas las
oficinas del banco acceden las aplicaciones a fuentes de datos centralizadas.
 Landscape: Suele llamar a como está compuesto un ambiente, por cuantos servidores, con
qué aplicativos.
 Licitacion: También denominada concurso público o contrato del Sector Público y privado)
es el procedimiento administrativo para la adquisición de un producto o servicio.
 Busisnes Intelligence: Se denomina inteligencia empresarial, inteligencia de
negocios o BI (del inglés business intelligence) al conjunto de estrategias y herramientas
enfocadas a la administración y creación de conocimiento mediante el análisis
de datos existentes en una organización o empresa.
 Sinergias: resultado de la acción conjunta de dos o más causas, pero caracterizado por tener
un efecto superior al que resulta de la simple suma de dichas causas.
 Workflow: El flujo de trabajo (workflow en inglés) es el estudio de los aspectos
operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan,
cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta
las tareas y cómo se le hace seguimiento al cumplimiento de las tareas.

81
 Testing: Las pruebas de Software son una actividad mas en el proceso de Aseguramiento
de la Calidad. Las Pruebas son básicamente un conjunto de actividades dentro del
desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser
implementadas en cualquier momento de dicho proceso de desarrollo.
 Netweaver: Es una plataforma de tecnología integrada para todas las aplicaciones SAP en
el plano técnico. Es conocida como una aplicación orientada a servicios y a la integración.
Provee al usuario de un vínculo entre lenguajes y aplicaciones. Está construido usando
estándares abiertos de la industria por lo que es sencillo negociar transacciones de
información con desarrollos de Microsoft .NET, Sun Java EE, e IBM WebSphere.
 PMBook: Es un estándar en la Administración de proyectos desarrollado por el Project
Management Institute (PMI). La misma comprende dos grandes secciones, la primera sobre
los procesos y contextos de un proyecto, la segunda sobre las áreas de conocimiento
específico para la gestión de un proyecto.
 CATT o ECATT: Subprogramas de rutina dentro SAP para poder modificar o crear
información en tablas.
 Repository: Espacio dedicado a un grupo especifico de datos.
 Workbench: Es una parte fundamental del sistema operativo del ordenador personal
 Sandbox: Es el aislamiento de procesos, mediante el cual, se pueden ejecutar distintos
programas con seguridad y de manera separada.

82