Archive for January, 2009

SAP_ALL o Permisos Amplios

Friday, January 30th, 2009

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

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

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

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

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

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

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

Perfiles de autorización

Thursday, January 29th, 2009

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La seguridad en SAP – Roles y permisos

Friday, January 23rd, 2009

Tema complicado si los hay… explicar como funciona la seguridad en SAP… trataré de hacer lo más simple posible algo lo suficientemente complicado.

Una vez que accedimos a SAP si nuestro usuario no tiene efectivamente ningún tipo de permiso al sistema (solo el acceso) no vamos a poder realizar ninguna actividad sobre el mismo.

La manera de asignar estos permisos es a través de Roles (alias Papeles, alias Grupos de Autorización).

Los Roles, son un medio para permitir que un usuario acceda a una transacción o pueda ejecutar una función determinada dentro de alguna transacción.

Para entender el concepto hace falta explicar el concepto de Objeto de Autorización: Es un objeto que nos brinda SAP como marco para crear Autorizaciones y es la unidad fundamental de la seguridad en SAP.

Un Objeto de Autorización tiene el siguiente formato:

Nombre del Objeto: S_TCODE (Permiso de acceso a las transacciones)
Campo: TCD (Código de Transacción)

Este es el objeto por excelencia (S_TCODE), en donde uno determina las transacciones a las que el usuario debería tener acceso. Para ser más claros:

Paso 1: El usuario pfernandez necesita acceder a las transacciones SU01 (ABM de Usuarios) y SU10 (Gestión de Usuarios en Lote)

Paso 2: Ante la necesidad se crea un ROL de nombre Z:GESTION_USUARIOS al cual se le asignan las dos transacciones en el menú a través de la transacción PFCG.

Paso 3: Automáticamente SAP crea una autorización para el rol Z:GESTION_USUARIOS para el objeto S_TCODE, al que le agrega en el campo TCD los valores: SU01 y SU10.

Paso 4: Se asigna al usuario pfernandez el rol Z:GESTION_USUARIOS dándole a través del mismo el acceso a las transacciones SU01 y SU10

Paso 5: El usuario  pfernandez, accede al sistema con su usuario y contraseña y una vez dentro, ejecuta la transacción SU01.

Paso 6: SAP analiza el pedido de ejecución de la transacción SU01, y se fija que entre los permisos de pfernandez se encuentre el objeto de autorización S_TCODE con el campo TCD con el valor SU01. Si es correcto permite el acceso a la transacción.

Cabe destacar que el control del objeto S_TCODE está implícito en SAP y se realiza siempre que se llama a una transacción, por eso el objeto S_TCODE es tan “popular” dentro de la segurida SAP

Esta explicación es a fines educativos solamente, más adelante vamos a ver que la generación de un rol, es mucho más compleja que los pasos seguidos anteriormente, pero da una idea general de como es el proceso.

También recuerden que según la versión de SAP con la que trabajemos a veces pueden llamarse Roles, o pueden ser Grupos de Autorización o en algún lugar también pueden ser Papeles.

Una explicación sobre perfiles la podemos ver en el siguiente post

En un próximo post también, vamos a explicar como es el proceso de autorización completo y con ejemplos de mayor complejidad.

Ejemplo en SAP del uso de la transacción PFCG

VN:F [1.8.2_1042]
Rating: 4.5/5 (2 votes cast)
VN:F [1.8.2_1042]
Rating: +1 (from 1 vote)

Módulos de SAP

Friday, January 23rd, 2009

SAP está organizado mediante módulos, agrupando las funcionalidades de distintas áreas de la organización, a su vez los módulos se dividen varios submódulos… algunos de los más conocidos los detallamos a continuación:

BC Basis (Administración del Sistema)
AM Asset Management  (Gestión de Activos Fijos)
CO Controlling (Contabilidad de Costos)
FI Financial Accounting  (Contabilidad Financiera)

  • FI-AP Accounts Payable (Cuentas a Pagar)
  • FI-AR Accounts Receibable (Cuentas a Cobrar)
  • FI-GL General Ledger (Libro de Mayor)
  • FI-TR Tresoury (Tesorería)
  • FI-LC Consolidation (Consolidación)
  • FI-BL Bank Ledger (Bancos)

HR Human Resources (Administración de Recursos Humanos)

  • HR-PY Payroll (Nómina)
  • HR-PA Personell Administration (Administración del personal)
  • HR-OM Gestión Organizacional

IS Industry Specific Solutions (Soluciones dependientes de la industria)
PM Plant Maintenance (Mantenimiento de Planta)
PP Production Planning (Planeamiento de la producción)
PS Project System (Gestión de Proyectos)
QM Quality Management (Control de Calidad)
SD Sales and Distribution (Ventas y Distribución)
MM Materials Management (Gestión de Materiales)
WF Business Work Flow

No necesariamente todos los módulos necesitan estar instalados en una implementación SAP, por ejempo muchas empresas solo manejan su contabilidad (Módulo FI) o no implementan los módulos de ventas SD o lo correspondiente a PP o PM por ser empresas de servicio.

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

Breve glosario del mundo SAP

Friday, January 23rd, 2009

Este glosario está en constante crecimiento por lo cual puedes ingresar habitualmente para encontrar nuevas definiciones o correcciones.

Haga click en la palabra clave para ir a documentos vinculados con el tema

Landscape: Conjunto de Ambientes y su distribución tanto física y lógica que brindan una solución integrada.

Ambiente: Sistema SAP compuesto por un application server y una base de datos

Instancia: Instalación o proceso independiente de un application server

Mandante: Conjunto de datos de acceso independiente dentro de una instancia de SAP

Transacción: Nomenclador para ejecutar un programa o una función en SAP R/3

ABAP: Lenguaje de programación habitual del entorno SAP R/3 en el que se codifican los programas, adicionlmente las aplicaciones pueden codificarse en Java lo cual está adquiriendo más popularidad, pero el core del permanece codificado en lenguaje ABAP.

ABAPER: Como comunmente se denomina a los programadores ABAP.

Customizing: Popularmente se llama así a la parametrización del sistema, NO AL CODIGO FUENTE. Habitualmente son las opciones que se encuentran disponibles dentro de la transacción SPRO y por las cuales se cambia el comportamiento del sistema en su conjunto o de transaccions individuales para adecuar el sistema a la organización donde se lo implementa.

Workbench: Habitualmente se denomina workbench al entorno de desarrollo y a todo lo que implique la manipulación de código fuente.

Ambiente de Producción: Ambiente donde se encuentran los datos operativos y donde los usuarios finales transaccionan. La información sensible de la organización se encuentra almacenada en el mismo.

Ambiente de Desarrollo: Ambiente independiente del de producción (debiera serlo) donde se desarrollan las modificaciones de workbench o customizing y las mismas luego de ser probadas son impactadas al ambiente de producción.

Ambiente de Pruebas: Ambiente donde se ejecutan las pruebas de las aplicaciones elaboradas en el ambiente de desarrollo o de las modificaciones al customizing realizadas también en el ambiente de desarrollo.

SAP GUI: Programa de interfaz del usuario final que debe ser instalada en la máquina cliente para poder conectarse y trabajar con SAP.

VN:F [1.8.2_1042]
Rating: 3.5/5 (2 votes cast)
VN:F [1.8.2_1042]
Rating: +1 (from 3 votes)

SAP y las tres capas

Thursday, January 22nd, 2009

SAP, en versiones anteriores era llamado como SAP R/3 haciendo referencia esta sigla a las 3 capas con las que trabajaba.

El concepto de 3 capas o three layers está hace bastante tiempo con nosotros y basicamente consiste en armar una aplicación dividiendo los datos en una capa (Base de datos), las reglas de negocio (Application Server), y la presentación de la información (el SAP GUI).

Esto se vio reflejado en al artículo sobre las instancias y los ambientes.

La capa de base de datos para SAP es un servidor de base de datos, el cual conceptualmente puede ser cualquiera (con determinados requisitos) siendo muchas veces utilizado Oracle, DB2, SQL Server, entre otros.

La capa de aplicación, son los application servers, los cuales también pueden ser ejecutados en distintas plataformas de sistema operativo. Esta capa es la que se encarga del procesamiento de los datos, la ejecución de los programas ABAP o JAVA, la validación de permisos, la comunicación con otras plataformas, entre varias cosas, y básicamente es la de mayor carga de procesamiento.

La capa de presentación por excelencia es el SAP GUI, y es el cliente que se encarga de dibujar la interfaz para con el usuario final. Actualmente existe la tendencia a llevar funcionalidades de SAP al explorador o mediante otras herramientas como ser el SAP Portal como capa intermedia.

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

Instancias y Ambientes

Thursday, January 22nd, 2009

En otros posts vimos como era un landscape estandar de SAP, con sus ambientes de desarrollo, testing (pruebas), producción. Pero aún nos falta profundizar el tema un poco más introduciendo algunos nuevos conceptos.

Cada ambiente (desarrollo, testing, producción) es una instalación distinta de SAP, a cada instalación se las llama instancia.

Básicamente a la instancia, la podemos definir como un sistema SAP independiente de otro, salvo por las conexiones que nosotros específicamente definamos. Entonces en este ejemplo, un ambiente de desarrollo, uno de testing y otro de producción son independientes entre si salvo que nosotros explícitamente conectemos estas instancias.

Estas instancias son instalaciones que pueden compartir un mismo equipo como en el caso de el presente gráfico:

servidor

Como también pueden encontrarse en equipos distintos, cada uno ejecutando una instancia:

servidores

El tema es aún más complejo… podríamos encontrar en un mismo equipo o en varios equipos distribuidas varias instancias que podemos llamar application servers y que atiendan a un mismo sistema de manera de poder distribuir la carga de transacciones entre distintos application servers.

servidores-2

Adicionalmente y para sumar complejidad, cada sistema debe tener su propia base de datos, de manera que un sistema productivo estándar podría tener un servidor productivo con una instancia de Application Server más un servidor de base de datos. O infinitas variantes con la base de datos instalada en el mismo application entre otras opciones posibles.

En un próximo post profundizaremos más en el tema y hablaremos también específicamente sobre el concepto de 3 capas.

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