Posts Tagged ‘Seguridad’

Parámetros de Seguridad (Parte II)

Friday, February 20th, 2009

Continuamos la lista que comenzamos a armar ayer con algunos de los últimos parámetros del sistema SAP:

Multiloguin

login/disable_multi_gui_login = Determina si el sistema permite logins desde más de un GUI. (o permite, 1 deshabilita). Es utilizado para evitar riesgos no detectados que un usuario sea utilizado desde más de una terminal, para ahorrar en términos de performance y para evitar problemas de licencias con SAP)

login/multi_login_users = En el se definen separados por comas, las excepciones al parámetro anterior, osea quienes pueden loguearse desde más de un gui independientemente de la definición del otro parámetro.

login/failed_user_auto_unlock = Aquí entre 0 y 1 se define si después de la medianoche los usuarios bloqueados por errores de contraseña se desbloquean automáticamente. Lo recomendable es que esto no suceda a diferencia del valor por defecto de SAP.

login/fails_to_session_end = En este caso se define la cantidad de errores en el ingreso de contraseña hasta que la sesión de un usuario llegué a su fin (pero no se bloquea el usuario, solo se lo desconecta del SAP GUI)

login/fails_to_user_lock = Este parámetro determina la cantidad de errores consecutivos en el ingreso de la contraseña a partir del cual se bloquea el usuario, el cual debe ser desbloqueado por el administrador salvo que el parámetro logins/failed_user_auto_unlock tenga un valor distinto de 0.

Otros parámetros

login/disable_cpic = A partir del mismo se deshabilitan las conexiones por el viejo protocolo CPIC.

login/no_automatic_user_sapstar = Este parámetro deshabilita el usuario harcodeado SAP* con contraseña PASS en caso que se borre el usuario SAP* del maestro de usuarios. (0 habilitado, 1 deshabilita). Para más información ver el artículo:  http://www.seguridadsap.com/sap/usuarios-por-defecto-sap-ddic-earlywatch-etc/.

rdisp/gui_auto_logout = Mediante este parámetro se determina en segundos la cantidad de tiempo de inactividad antes que se terminé la sesión del usuario (0 deshabilitado)

login/system_client = El mismo define el mandante por defecto que nos aparecerá propuesto.

El presente post y su parte uno fueron una enumeración de los principales parámetros vinculados con la seguridad de SAP, respecto a los valores recomendados probablemente en breve hagamos una entrada nueva en este blog definiéndolos, aunque siempre teniendo en cuenta que es muy personal de cada instalación.

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

Parámetros de configuración de Seguridad

Thursday, February 19th, 2009

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

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

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

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

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

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

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

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

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

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

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

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

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

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

login/password_compliance_with_current_policy = Este parámetro determina que durante los nuevos logins se verifique si la contraseña cumple con el estándar actualmente definido. (o no chequea, 1 chequea) De esta manera las modificaciones de parámetros de seguridad impactarán inmediatamente en los usuarios requiriendo que los mismos realicen un cambio de contraseñas en su próximo loguin si no cumplen la política actual.

login/password_max_idle_initial = Máximo número de días que la contraseña definida por el administrador (inicial) puede permanecer habilitada para que el usuario la utilice. (0 a 1000). Es utilizado para evitar que los usuarios sean dados de alta con contraseñas iniciales pero nunca ingresen al sistema dejando una puerta semi-abierta en el mismo sistema (contraseñas iniciales débiles)

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

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

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

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

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

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

La seguridad en SAP – Roles y permisos (ejemplo)

Tuesday, February 17th, 2009

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

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

image

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

image

image

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

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

image

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

image

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

image

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

image

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

image

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

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

Algunas Transacciones Importantes

Monday, February 2nd, 2009

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

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

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

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

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

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

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

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

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

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

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

SAP_ALL o Permisos Amplios

Friday, January 30th, 2009

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

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

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

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

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

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

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

Perfiles de autorización

Thursday, January 29th, 2009

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.9.10_1130]
Rating: 4.8/5 (4 votes cast)
VN:F [1.9.10_1130]
Rating: +1 (from 1 vote)