instituto politÉcnico nacionaltesis.ipn.mx/jspui/bitstream/123456789/15093/1/i.c.e. 28-13.pdf ·...
TRANSCRIPT
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:
México D.F OCTUBRE 2012
ISRAEL ROJAS LUNA
I
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.
II
Í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
III
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
IV
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
V
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
VI
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.
VII
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.
1
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.
2
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
Desarrollo
Ambiente
Testing/Calidad
Ambiente
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.
3
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.
4
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
5
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:
6
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.
7
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.
8
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)
9
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.
10
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.
11
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
12
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.
13
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.
14
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.
15
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.
16
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.
17
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
18
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.
19
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.
20
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.
21
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.
22
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.
23
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..
24
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
25
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.
26
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.
27
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.
28
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.
29
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.
30
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.
31
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.
32
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.
33
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
34
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.
35
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
36
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.
37
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
38
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.
39
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
40
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
41
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
42
- 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
43
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
44
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
45
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
46
(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
47
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
48
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.
49
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
50
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.
51
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
52
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
53
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
54
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
55
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).
56
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
57
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
58
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
59
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
60
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
61
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
62
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
63
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
64
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.
65
¿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
66
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
67
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
68
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
69
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.
70
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
71
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.
72
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.
73
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:
74
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.
75
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
76
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.
77
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.
78
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.
79
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.
80
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
81
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.
82
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.