Conceptos de seguridad SAP
La seguridad en SAP es multinivel, abarcando desde la infraestructura técnica hasta las autorizaciones funcionales de cada usuario. Un sistema SAP correctamente asegurado protege datos corporativos críticos, cumple normativas legales y previene accesos no autorizados tanto externos como internos.
El modelo de seguridad SAP se basa en el principio de menor privilegio: cada usuario debe tener únicamente los permisos necesarios para realizar su trabajo, nada más. Este principio aplicado consistentemente minimiza riesgos de fraude, errores accidentales y exposición de información sensible.
La seguridad SAP se estructura en capas: seguridad de red controlando qué sistemas pueden comunicarse, seguridad de autenticación verificando identidades, seguridad de autorización determinando qué operaciones puede realizar cada usuario, seguridad de datos protegiendo información en reposo y en tránsito, y auditoría registrando todas las actividades sensibles para revisión posterior.
Las responsabilidades de seguridad se reparten entre diferentes equipos: BASIS gestiona seguridad técnica del sistema, consultores de seguridad diseñan roles y autorizaciones funcionales, auditores verifican cumplimiento de políticas, y usuarios finales son responsables de proteger sus credenciales y reportar incidentes.
Autenticación y autorización
La autenticación verifica la identidad del usuario mediante credenciales. La autorización determina qué puede hacer ese usuario una vez autenticado. Ambos conceptos son fundamentales pero distintos.
SAP soporta múltiples métodos de autenticación. La autenticación básica utiliza usuario y password almacenados en tabla USR02. Single Sign-On (SSO) permite que usuarios autenticados en el dominio corporativo accedan a SAP sin ingresar password adicional, mejorando experiencia de usuario y seguridad. Los certificados X.509 proporcionan autenticación fuerte basada en criptografía de clave pública. La autenticación multifactor añade capa adicional requiriendo segundo factor como token o app móvil.
Las políticas de password se configuran en tabla USR40 mediante transacción SECPOL. Las configuraciones incluyen longitud mínima de password (recomendado 8+ caracteres), complejidad requerida (mayúsculas, minúsculas, números, caracteres especiales), expiración periódica (típicamente 90 días), historial de passwords previniendo reutilización, y bloqueo de cuenta tras intentos fallidos (típicamente 5 intentos).
El concepto de autorización en SAP se basa en objetos de autorización. Cada operación en SAP (ejecutar transacción, leer tabla, modificar orden de compra) está protegida por objetos de autorización que contienen campos con valores permitidos. Los roles SAP agrupan conjuntos de autorizaciones relacionadas según funciones de negocio.
Roles y perfiles
Los roles SAP agrupan autorizaciones relacionadas según funciones de negocio. Un rol puede contener permisos para ejecutar transacciones, acceder a datos específicos, ejecutar reportes y otras operaciones. Los perfiles son colecciones técnicas de objetos de autorización que implementan los permisos del rol.
La transacción PFCG (Profile Generator) es la herramienta principal para gestionar roles. El proceso de creación de rol incluye definir el rol y su descripción, asignar transacciones que el rol puede ejecutar, generar automáticamente las autorizaciones necesarias para esas transacciones, ajustar manualmente autorizaciones específicas para refinar permisos, generar el perfil técnico, y asignar el rol a usuarios en SU01.
Los tipos de roles incluyen Single Roles que contienen autorizaciones específicas para una función, Composite Roles que agrupan múltiples single roles facilitando asignación a usuarios, y Derived Roles que heredan autorizaciones de un rol master pero con valores organizacionales diferentes (útil para separar por compañía, centro, o división).
El principio de segregación de funciones (SoD) es crítico. Ciertas combinaciones de autorizaciones crean riesgos de fraude. Por ejemplo, un usuario no debería poder crear vendors y también aprobar pagos a esos vendors. Las herramientas como SAP GRC Access Control ayudan a detectar y prevenir conflictos SoD.
La gestión de roles requiere mantenimiento continuo. Cuando se modifican roles en desarrollo, los cambios deben transportarse a producción mediante órdenes de transporte. Los roles deben revisarse periódicamente para remover autorizaciones obsoletas, ajustar permisos según cambios de procesos de negocio, y asegurar que siguen principio de menor privilegio.
Seguridad técnica (BASIS)
Los administradores BASIS son responsables de la seguridad técnica del sistema. Esta capa protege la infraestructura SAP independiente de autorizaciones funcionales.
La aplicación de Security Notes de SAP es tarea crítica. SAP publica regularmente notas que corrigen vulnerabilidades de seguridad. Los administradores deben revisar SAP Security Notes semanalmente, priorizar notas críticas según criticidad y exposición del sistema, testear en QAS antes de aplicar en PRD, y documentar aplicación para auditorías. La transacción SNOTE facilita aplicación de notas.
Los parámetros de seguridad del sistema se configuran en perfiles (RZ10). Los parámetros críticos incluyen login/fails_to_user_lock que define intentos fallidos antes de bloqueo, login/disable_multi_gui_login para prevenir sesiones concurrentes del mismo usuario, login/password_expiration_time para forzar cambios periódicos de password, auth/rfc_authority_check para verificar autorizaciones en llamadas RFC, y gw/acl_mode para control de acceso al gateway.
La gestión de usuarios técnicos requiere atención especial. Los usuarios SAP* y DDIC tienen privilegios elevados y deben protegerse rigurosamente: cambiar passwords de default inmediatamente post-instalación, documentar quién conoce estos passwords, limitar su uso a emergencias, auditar todo uso de estos usuarios, y considerar su desactivación en producción si no son necesarios.
Los programas registrados en SM59 (destinos RFC) y SM69 (comandos externos) representan potenciales vectores de ataque. Solo programas y comandos necesarios deben estar registrados, cada entrada debe tener justificación de negocio documentada, y acceso a transacciones SM59/SM69 debe estar restringido a administradores BASIS.
Seguridad en SAP HANA
SAP HANA tiene modelo de seguridad propio adicional al de la capa de aplicación SAP. Los administradores deben securizar ambas capas.
Los usuarios de HANA son independientes de usuarios SAP. Cada usuario HANA tiene privilegios específicos: SYSTEM tiene control total (equivalente a SAP* en ABAP), usuarios de esquema acceden a objetos específicos de base de datos, y usuarios de aplicación ejecutan consultas según permisos otorgados. La gestión de usuarios HANA se realiza mediante HANA Studio o Cockpit.
Los roles de HANA otorgan privilegios a nivel de base de datos. Los tipos de privilegios incluyen system privileges para operaciones administrativas, object privileges para acceso a tablas y vistas específicas, analytical privileges para control granular en vistas analíticas, y package privileges para desarrollo de objetos HANA.
El cifrado de datos en HANA protege información sensible. HANA soporta encryption at rest mediante cifrado de data volumes y log volumes usando tecnologías del sistema operativo o HSM (Hardware Security Module), y encryption in transit mediante SSL/TLS para todas las conexiones de red hacia HANA.
El auditing de HANA registra actividades críticas. La configuración de audit policy define qué eventos auditar: intentos de autenticación exitosos y fallidos, accesos a tablas sensibles, cambios de privilegios y roles, y operaciones administrativas. Los audit logs deben revisarse regularmente y archivarse para cumplimiento.
Seguridad en SAP Fiori
Las aplicaciones Fiori exponen funcionalidades SAP vía web, creando nueva superficie de ataque que debe protegerse adecuadamente.
La autenticación en Fiori debe utilizar métodos seguros. El SSO mediante SAML es el approach recomendado: usuarios se autentican en Identity Provider corporativo una vez y acceden a Fiori sin password adicional. La autenticación básica con usuario/password debe evitarse o al menos requerir HTTPS obligatorio.
Las autorizaciones Fiori tienen dos componentes. Primero, autorización para ver el tile en Launchpad mediante catálogos y grupos asignados al rol del usuario. Segundo, autorizaciones backend para ejecutar las operaciones que la app Fiori invoca mediante servicios OData. Ambas capas deben configurarse correctamente.
La seguridad de Gateway es crítica ya que expone servicios SAP vía HTTP. Los servicios OData deben protegerse mediante objeto de autorización S_SERVICE verificando que usuario tiene permiso para ejecutar el servicio específico. A nivel de datos, los servicios deben implementar filtros de autorización evitando que usuarios accedan a datos fuera de su alcance organizacional.
El transport security requiere HTTPS para toda comunicación entre navegador y Frontend Server. Los certificados SSL deben ser válidos (no auto-firmados en producción), emitidos por CA reconocida, y actualizados antes de expiración. La comunicación entre FES y backend también debe securizarse especialmente si atraviesa redes no confiables.
Certificados y SSL en SAP
Los certificados digitales son fundamentales para autenticación fuerte y cifrado de comunicaciones. SAP utiliza certificados en múltiples escenarios.
El Trust Manager (transacción STRUST) gestiona certificados en SAP. Los PSE (Personal Security Environment) almacenan certificados y claves privadas. Los PSE típicos incluyen SSL Server Standard PSE para conexiones HTTPS entrantes, SSL Client Standard PSE para conexiones HTTPS salientes, y SNC PSE para Secure Network Communications.
La implementación de HTTPS en SAP requiere varios pasos: generar Certificate Signing Request (CSR) en STRUST, enviar CSR a Certificate Authority para firma, importar certificado firmado más certificados intermedios en el PSE, activar SSL en el ICM mediante parámetros de perfil, y configurar puertos HTTPS en SMICM.
La monitorización de certificados previene expiraciones inesperadas. Los certificados típicamente expiran anualmente o cada dos años. El proceso incluye identificar certificados por vencer (revisar STRUST mensualmente), generar nuevos CSRs con anticipación, obtener certificados renovados de la CA, importar en PRD durante ventana de mantenimiento, y verificar que aplicaciones funcionan correctamente con nuevos certificados.
Los SNC (Secure Network Communications) permiten autenticación y cifrado de conexiones RFC entre sistemas SAP. Esto es especialmente importante para landscapes distribuidos donde RFC atraviesa redes no seguras. La configuración SNC requiere certificados en ambos sistemas y parámetros específicos en destinos RFC (SM59).
Auditoría y trazabilidad
La auditoría registra actividades en el sistema permitiendo detectar comportamientos sospechosos y demostrar cumplimiento de políticas. SAP proporciona múltiples mecanismos de auditoría.
El Security Audit Log (transacciones SM19/SM20) registra eventos de seguridad. SM19 configura qué eventos auditar: inicios de sesión exitosos y fallidos, cambios en maestro de usuarios, ejecución de transacciones críticas, cambios en roles y autorizaciones, accesos a datos sensibles mediante table logging, y uso de funciones administrativas críticas. SM20 permite analizar los logs generados filtrar por usuario, transacción, o evento específico.
El Change Documents framework registra cambios en datos maestros y transaccionales. Cuando un usuario modifica una orden de compra, cliente, o material, el sistema registra qué campos cambiaron, valores antes y después, usuario que realizó el cambio, y timestamp. Esta información es crucial para auditorías y troubleshooting.
El Table Logging permite auditoría granular de tablas específicas. Para tablas conteniendo datos especialmente sensibles, se activa logging (SE13) que registra cada insert, update y delete. Esto consume recursos adicionales pero proporciona audit trail completo de cambios críticos.
Los reportes de auditoría deben ejecutarse periódicamente. Análisis típicos incluyen usuarios con actividad fuera de horario laboral, múltiples intentos fallidos de login, cambios en roles con privilegios elevados, accesos a datos confidenciales, y uso de usuarios técnicos que deberían estar inactivos. Las anomalías detectadas requieren investigación.
Temas relacionados
Páginas relacionadas
Para profundizar en seguridad SAP y su implementación, consulta también:
SAP BASIS para aspectos de administración técnica de seguridad.
SAP Fiori para seguridad en aplicaciones web.
SAP HANA para seguridad específica de la base de datos.
Operación SAP para procedimientos operativos de seguridad.