Configuration et contrôle des paramètres kernel du SAP Security Audit Log (SAL)

Pour l’audit d’un système SAP, le Security Audit Log (SAL) est l’une des sources les plus importantes. Avec l’EHP 7, la façon de le configurer a changé : à côté des paramètres de profil, il existe des paramètres kernel qui s’appliquent à l’échelle du système et ont la priorité. Qui l’ignore contrôle au mauvais endroit.

Pourquoi le Security Audit Log compte pour l’audit

Un système ERP est soumis à des exigences légales sur l’exactitude des données et la traçabilité des modifications. Il en découle en pratique un paysage système composé au minimum d’un développement et d’une production, et la séparation des tâches entre l’informatique et les métiers. Sont particulièrement critiques les accès qui suspendent délibérément cette séparation, comme les interventions d’utilisateurs d’urgence.

C’est exactement là qu’intervient le Security Audit Log : il journalise les événements pertinents pour la sécurité, par utilisateur, dans une zone protégée, indépendamment des documents de modification de l’application. Dans l’audit interne et dans l’audit des comptes annuels, il est donc une source de preuve centrale. Pour que la preuve tienne, le journal doit être complet, permanent et configuré de la même façon sur toutes les instances.

Configuration jusqu’à l’EHP 6 : paramètres de profil et SM19

Jusqu’à l’EHP 6, le Security Audit Log se configure dans la transaction SM19, en deux variantes :

• Configuration statique : les réglages sont stockés comme paramètres de profil ou d’instance dans la base de données et sont actifs après chaque démarrage du système. L’exploitation permanente exige une configuration statique active. Des filtres définissent quels utilisateurs ou groupes d’utilisateurs sont enregistrés ; le nombre de filtres possibles dépend de la release.
• Configuration dynamique : le journal peut être activé et adapté en cours d’exploitation, sans redémarrage. Seul le nombre de filtres parallèles est fixé.

On règle entre autres les mandants à journaliser, les classes d’audit (par exemple connexion en dialogue ou connexion RFC), la catégorie d’événements (tous, critiques, graves) ainsi que la taille et l’emplacement des fichiers d’audit. Les paramètres de profil les plus importants sont rsau/enable (journal activé ou non), rsau/selection_slots (nombre de filtres), rsau/user_selection (filtre utilisateur) et rsau/max_diskspace/local (espace disque).

Lors de l’audit, on vérifie habituellement dans la transaction RZ10 si ces paramètres respectent les exigences réglementaires, les directives de l’entreprise ou les recommandations usuelles. En complément, la table PAHI montre si des paramètres ont été modifiés à brève échéance, par exemple juste avant l’audit.

À partir de l’EHP 7 : paramètres kernel dans SM19

Avec l’EHP 7, l’onglet « Paramètres kernel » a été ajouté à SM19. Il active et configure le Security Audit Log à l’échelle du système, de la même manière que les politiques de sécurité pour les mots de passe (SECPOL) s’appliquent à l’échelle du système. Trois points sont décisifs :

1. Les paramètres kernel supplantent les paramètres de profil. Dès qu’ils sont définis, les paramètres de profil rsau/* connus sont sans effet. Qui veut continuer à travailler avec les paramètres de profil doit désactiver les paramètres kernel.
2. La maintenance ne se fait plus dans RZ10, mais directement dans le Security Audit Log. RZ10 peut donc afficher une valeur qui ne s’applique pas.
3. Les valeurs sont stockées dans la table RSAUPROF. Le système crée pour cela des profils nommés $KERNEL$ ; chaque slot représente un paramètre. Le slot 0006, par exemple, décide si plusieurs fichiers d’audit sont écrits par jour.

Une demande de confirmation apparaît à l’activation. Si l’on y répond par non, les serveurs d’application ne sont pas configurés de manière homogène.

Ce que cela signifie pour l’audit

Un audit qui ne lit que les paramètres de profil peut induire en erreur à partir de l’EHP 7 : un journal apparemment désactivé via rsau/enable = 0 peut très bien être actif grâce aux paramètres kernel, et inversement un paramètre de profil défini ne dit rien de ce qui est réellement journalisé. L’historique des modifications se trouve lui aussi à un autre endroit : les modifications des paramètres kernel ne figurent pas dans PAHI, mais sont écrites via la journalisation des tables (rec/client) pour RSAUPROF.

Pour l’audit, cela signifie :

• Lire les deux endroits : les paramètres de profil dans RZ10 et l’onglet « Paramètres kernel » dans SM19.
• Établir ce qui s’applique : si des paramètres kernel sont actifs, ce sont eux qui comptent, pas les paramètres de profil.
• Exploiter l’historique : avec le rapport RSTBHIST (par exemple via SA38) pour la table RSAUPROF, en recherchant les profils $KERNEL$. PAHI seule ne suffit pas.
• Vérifier la cohérence : avec les paramètres kernel, le réglage s’applique à l’échelle du système ; avec les paramètres de profil, la comparaison entre toutes les instances reste nécessaire.

Notre appréciation

Du point de vue de la compliance, la nouveauté est un progrès. Les paramètres kernel s’appliquent à l’échelle du système après le redémarrage ; le risque que la distribution vers certains serveurs d’application échoue et que le journal y manque disparaît. L’auditeur n’a plus à vérifier la cohérence de chaque instance une à une.

Deux choses restent insatisfaisantes. Selon la release, il y a deux endroits à contrôler, les paramètres de profil et SM19. Et la table RSAUPROF était conçue pour les filtres ; avec les profils $KERNEL$, elle est détournée de son usage, et la structure hétérogène rend l’exploitation plus laborieuse qu’elle ne devrait l’être.

Remarque : dans les releases plus récentes (à partir de SAP NetWeaver 7.50 avec le Support Package 03, donc aussi dans S/4HANA), les transactions RSAU_CONFIG, RSAU_READ_LOG et RSAU_ADMIN remplacent SM19, SM20 et SM18. La distinction entre paramètres de profil et paramètres kernel et le stockage dans RSAUPROF demeurent.

Une version plus détaillée de cet article, en allemand et avec des captures d’écran, est parue sur le blog d’experts rz10.de : Kernel-Parameter für das SAP Security Audit Log (SAL): Vorsicht vor Inkonsistenzen.