Preguntale al Basis

En el ámbito de las autorizaciones de los sistemas SAP y mas en el ERP, siempre los entes auditores, hacen mucho énfasis o generan reportes de no conformidad, mencionando que las transacciones relacionadas con los queries (sq01, sq02, sq03) como las relacionadas con la ejecución de los programas SE38 o SA38 y que son asignadas a los usuarios, representan un alto riesgo para la seguridad del sistema, obviamente dando las explicaciones correspondientes sobre el impacto de las mismas. Pero teniéndolas bien controladas o creando estrategias de su uso, se pueden mitigar esos riesgos. Para ello y de acuerdo con mi experiencia, consignare las estrategias que existen con el fin de reducir los riesgos o al menos con el fin de presentar los controles que se tienen para mitigar estos riesgos que por cierto siempre lo califican como de alto riesgo, poniendo en alerta a los directores de TI. Empezaré por nombrar donde se e encuentra el riesgo. Para las transacciones de los queries, el

  Muchas veces cuando monitoreamos el sistema SAP ERP y sobre todo los work process (que es en donde se procesan las peticiones que hace el usuario) a través de la transacción sm50 o en su defecto en la sm66, observamos que en la columna action, algunas veces se refleja el texto “sequential read”, tal y como se observa en la imagen siguiente: En múltiples ocasiones nos sorprendemos y caemos en lo que lo que en el ámbito de base de datos se denomina lectura secuencial, que para quienes hemos trabajados en base de datos o estudiamos en la universidad, nos enseñaron que es uno de los métodos más ineficaces e ineficientes para construir consultas. La verdad desde el punto de vista técnico, resulta ser un término muy engañoso, ya que por lo general suele ser comparado con este método ineficaz. Quiero aclarar que no obedece a lo mismo, aunque el mensaje así lo pareciese. Este método “sequential read” cuando aparece en la sm50, se refiere a todos los demás accesos a la b

Dentro del proceso de asignación de roles a un usuario, solemos cometer varios errores que a simple vista parece no tener ninguna repercusión pero que si lo miramos desde el punto de vista técnico y en detalle, generan una serie de eventos que suelen afectar varios elementos, entre los que se encuentran, comprometer recursos de memoria del sistema SAP, duplicidad en la asignación de roles, con fecha de caducidad diferentes, tareas de gestión que se vuelven bastante engorrosas y más cuando o se acerca la auditoria o se identifica el pecado, mediante el uso de las herramientas que los entes de auditoria suelen realizar. Lo cierto es que en últimas son sobrecostos en el que incurrimos a la hora de administrar un sistema SAP en el ámbito de los roles de seguridad y es por eso que daré algunos tips para que podamos resolverlo de una manera más ágil. Antes de mencionarlos, debo recordar algunos conceptos: ·      Entre más roles tenga asignado un usuario son más los r

Muchas veces el cambio y/o asignación de contraseñas se pueden volver complejo y dispendioso, convirtiéndose en una tarea que genera demasiada carga administrativa, pues al verse como  una tarea muy sencilla, deriva en 2 procesos, uno en cuanto a operación y trazabilidad por aquello de mantener sentado un registro para el área de auditora, que dicho de manera concreta es mucho el protocolo que maneja, además del tiempo que conlleva y el otro el proceso en sí que en realidad no conlleva más de tres clic  exagerando. Para reducir un poco esa gestión y volverla más automática y ágil, existen algunas soluciones que podrían apoyarla, a saber: ·          Una posible solución es utilizar la opción del CUA, pero como desventaja sigue siendo dependiente del área de TI, generando la misma carga administrativa, digamos que ayuda un poco en la gestión, ya que desde un solo sitio se pueda realizar el cambio, sin la necesidad de ingresar a cada sistema. ·          Ot

Una de las formas de mantener un sistema bajo un control absoluto desde el punto de vista de acceso hacia el sistema junto con otras variables, es a través del log de auditoria, donde dependiendo de lo que requieras auditar o mejor de lo que el ente de auditoria te exija habilitar debes tener en cuenta y claro, ya que la forma como opera pues dependiendo de cómo lo actives y dependiendo del volumen de usuarios y el acceso simultaneo podrías llegar afectar el rendimiento del sistema. A lo largo de mi experiencia he visto que este log lo activan de manera inadecuada pues habilitan todos los eventos que en realidad lo que hacen es cargar el sistema de información innecesaria y lo peor es que casi nunca consultan. De lo que llevo con SAP, lo único valioso que he podido identificar es el acceso hacia las transacciones, aunque también podrían ser valiosos, los accesos de logon y de logoff. El punto no está en lo que brinda sino en la forma como opera, y en este ámbito nos enco

Actualización de support packages en un sistema SAP Dentro del proceso de mejoramiento e innovación que SAP ha venido desarrollando nos encontramos con uno de ellos como es la actualización de support packages a un sistema SAP, en donde hoy por hoy y después de un uso prolongado del sistema convencional que se venía utilizando como era la transacción SPAM para el nivel abap y jspm para el nivel java, haya sido cambiada por una herramienta más sofisticada como es el SUM (software update manager). Antes de entrar de lleno al tema quiero aclarar que una actualización de support packages no es más que una actualización del software, valga la redundancia, que se le hace al sistema para aplicarles mejoras y corregir bugs que se han encontrado con el fin de ofrecer más bondades o en su defecto quitar opciones que tal vez pudieran ya estar obsoletas o sean innecesarias para el funcionamiento a la operación. En este contexto debo aclarar que a diferencia de una nota oss, esta

Desarrollos ABAP (programas zeta del cliente) que van orientados a sentencias SQL y que por lo general por estar mal construidos la mayoría de las veces castigan al sistema. En este frente son muchas las razones por las que un sistema se ve afectado a nivel de rendimiento, a continuación, las posibles causas más frecuentes: 1.        La mayoría de los casos ocurre porque el programa zeta construido para satisfacer una necesidad no está leyendo los índices creados. 2.        En algunos casos los programas zeta no están construidos cumpliendo las buenas prácticas, por nombrar alguno de ellos, el select *, crear más de tres join en una sentencia, entre otros. 3.        Inconvenientes con el tamaño de los índices, estos tienen igual o mayor tamaño que la tabla. Solo se deben reconstruir a través de la se14, por lo general un índice no debe ocupar más del 10% del tamaño de la tabla, máximo un 20% exagerando. 4.        Problemas con los programas e