Cette application auto-hébergée laisse-t-elle une piste d’audit ? Checklist pour les acheteurs

La journalisation d’audit est un critère de sélection d’application

Une application auto-hébergée peut être facile à déployer tout en étant mal adaptée à des données nécessitant un usage traçable et responsable. Si l’application doit contenir des données métier clients, employés, financières, opérationnelles ou autrement sensibles, posez-vous très tôt une question : l’équipe pourra-t-elle établir ultérieurement qui a fait quoi, sur quel objet, à quel moment et par quelle interface ?

Cette question dépasse la réponse aux incidents. Une piste d’audit exploitable peut contribuer à l’enquête sur une modification inattendue, aux workflows d’approbation et de gestion des exceptions, aux revues périodiques des accès, à la responsabilisation pour les changements de configuration et à la collecte d’éléments probants après un litige. Les recommandations du NIST relatives à la connaissance des événements identifient l’interaction utilisateur et le temps, les actions de configuration, ainsi que l’accès aux données stockées et leur utilisation comme des capacités pertinentes pour l’audit. Source : [NIST, Cybersecurity Event Awareness](https://pages.nist.gov/FederalProfile-8259A/technical/event/).

Ne considérez pas « il y a des journaux » comme une réponse suffisante. L’auditabilité est une propriété du produit et du déploiement. L’application doit générer les événements nécessaires, le déploiement doit les conserver, les examinateurs autorisés doivent pouvoir les retrouver et les interpréter, et des contrôles doivent les protéger contre toute modification ou suppression non autorisée.

• Faites de l’auditabilité une exigence notée avant de sélectionner une application, plutôt qu’une tâche reportée après la mise en production.
• Formulez les exigences en fonction des décisions que les enregistrements doivent permettre de prendre, par exemple : « identifier qui a accordé un rôle » ou « examiner les exportations de dossiers clients ».
• Attribuez la responsabilité des paramètres d’audit de l’application, des procédures de revue des journaux, des décisions de conservation et de l’accès aux éléments probants exportés.

Les journaux opérationnels, les journaux d’audit et l’historique de base de données répondent à des questions différentes

Les journaux opérationnels servent principalement à faire fonctionner les logiciels. Les pilotes de journalisation Docker collectent des informations provenant des conteneurs et services en cours d’exécution ; le pilote json-file est le pilote par défaut, sauf si une autre configuration est utilisée. Ces enregistrements peuvent aider à diagnostiquer un crash, un avertissement ou une erreur d’exécution, mais ils n’établissent pas intrinsèquement qu’un utilisateur métier nommé a modifié une fiche client précise. Docker indique aussi que json-file ne réalise pas de rotation des journaux par défaut, ce qui ne constitue pas à lui seul une stratégie de conservation prête pour une enquête. Source : [Docker, Configure logging drivers](https://docs.docker.com/engine/logging/configure/).

Les journaux de proxy inverse décrivent une autre couche. Traefik distingue ses propres journaux, qui couvrent notamment le démarrage, la configuration, les événements et l’arrêt, des journaux d’accès correspondant aux requêtes traitées par le proxy. Les journaux d’accès peuvent établir qu’une requête a atteint un endpoint, mais peuvent ne pas identifier de manière fiable l’acteur métier authentifié, l’objet métier affecté ou le résultat de l’action. Certains champs peuvent également être délibérément conservés, supprimés ou masqués. Source : [Traefik, Logs and Access Logs](https://doc.traefik.io/traefik/observe/logs-and-access-logs/).

L’historique de la base de données est encore différent. Le journal de transactions anticipées de PostgreSQL (write-ahead logging, WAL) enregistre les modifications des fichiers de données avant que les fichiers sous-jacents ne soient modifiés, afin que la récupération puisse réappliquer les changements après un crash. Le décodage logique peut rendre lisibles depuis le WAL les modifications persistantes des tables. Aucun de ces mécanismes ne fournit automatiquement un récit métier prêt pour une enquête : le contexte applicatif, l’identité de l’utilisateur, le contexte d’autorisation et la signification d’une modification peuvent manquer ou être difficiles à reconstituer. Sources : [PostgreSQL, WAL](https://www.postgresql.org/docs/15/wal-intro.html) et [Logical Decoding Concepts](https://www.postgresql.org/docs/17/logicaldecoding-explanation.html).

Utilisez chaque source pour l’objectif qui lui convient. Les journaux opérationnels et de proxy restent précieux pour le dépannage et les enquêtes d’infrastructure. Les mécanismes de base de données peuvent être utiles pour la récupération ou l’analyse technique. Mais ne substituez aucun d’eux à des enregistrements d’audit au niveau applicatif sans vérifier qu’ils répondent au besoin réel en matière de preuve.

• Journal opérationnel : « Qu’a signalé le processus ou le conteneur ? »
• Journal d’accès du proxy : « Quelle requête la périphérie a-t-elle traitée ? »
• Historique de base de données : « Quelle modification au niveau du stockage a eu lieu ? »
• Enregistrement d’audit applicatif : « Quel acteur a effectué quelle action métier ou administrative significative, sur quoi, quand et avec quel résultat ? »

Commencez par les décisions que la piste doit étayer

Une longue liste d’événements ne constitue pas une exigence. Commencez par lister les questions auxquelles un examinateur doit pouvoir répondre dans des conditions réalistes. Cela évite aux équipes de surévaluer une journalisation technique à fort volume tout en négligeant les quelques actions qui créent le plus grand risque métier.

Par exemple, une revue trimestrielle des accès requiert des informations fiables sur les appartenances et les changements de rôles. Une enquête sur des données financières modifiées peut nécessiter l’entité concernée, les valeurs avant et après lorsque cela est approprié, l’identité de l’acteur, l’heure et le résultat de l’action. Un workflow d’approbation peut exiger la preuve qu’une personne désignée a approuvé, rejeté ou contourné une étape. Les champs exacts et la durée de conservation doivent découler de ces questions.

Rendez le périmètre explicite. Un système peut auditer l’activité des administrateurs sans auditer les modifications des utilisateurs ordinaires, ou enregistrer les authentifications réussies sans enregistrer les échecs. Aucun de ces cas n’est intrinsèquement inacceptable ; la question est de savoir si la couverture documentée et testée correspond à vos cas d’usage déclarés.

• Enquêtes : pouvez-vous identifier l’acteur, l’objet, l’action, l’heure, le résultat et le contexte pertinent ?
• Approbations : pouvez-vous démontrer qui a approuvé, rejeté, délégué ou modifié une règle d’approbation ?
• Revues des accès : pouvez-vous identifier les appartenances, les rôles, les changements d’autorisations et l’acteur responsable ?
• Responsabilisation des changements : pouvez-vous retracer les changements de configuration administrative, les changements d’intégration et les paramètres pertinents pour la sécurité ?
• Revue de l’utilisation des données : pouvez-vous identifier l’accès aux données sensibles stockées et les actions à haut risque, telles que les exportations, lorsque votre politique l’exige ?

Événements à vérifier avant l’adoption

Utilisez la documentation officielle de l’application pour identifier les familles d’événements, puis associez-les à vos cas d’usage. Ne supposez pas qu’un événement décrit dans la documentation est activé, stocké ou disponible dans tous les modes de déploiement. Par exemple, la documentation de Keycloak précise que les événements utilisateur ne sont ni stockés ni affichés par défaut tant qu’un administrateur n’a pas activé leur enregistrement. Elle prévoit également une durée d’expiration du stockage des événements et des commandes permettant de supprimer les événements enregistrés. Source : [Keycloak, Server Administration Guide](https://www.keycloak.org/docs/latest/server_admin/).

L’activité d’authentification et d’autorisation constitue un point de départ : connexions réussies, connexions échouées, récupération de compte lorsqu’elle est pertinente, événements liés aux sessions lorsqu’ils sont documentés, changements de rôles ou de groupes et changements de privilèges. Pour l’activité administrative, incluez les changements effectués dans l’interface de gestion et, lorsque cela importe, les API de gestion. Keycloak documente l’audit des actions d’administrateur dans son Admin Console et des invocations REST utilisées pour ces actions. Source : [Keycloak, Server Administration Guide](https://www.keycloak.org/docs/latest/server_admin/).

La couverture des données métier mérite un examen distinct. Recherchez la création, la mise à jour, la suppression, l’accès ou l’utilisation de données sensibles stockées lorsque cela est requis, les opérations en masse, les exportations, les importations, les modifications de partage et les changements d’identifiants ou de connecteurs d’intégration. Une application peut offrir un excellent audit administratif tout en procurant une visibilité limitée sur les actions effectuées sur les enregistrements métier individuels.

Un événement utile doit contenir suffisamment de contexte pour être interprété ultérieurement. Le schéma d’événements d’audit publié par GitLab illustre une base de comparaison solide : identité de l’auteur, horodatage de l’événement, identification et type de l’entité, type d’événement, identifiant unique d’événement et informations supplémentaires. L’application que vous choisissez n’a pas besoin d’utiliser le même schéma, mais ses enregistrements doivent répondre à des questions équivalentes pour vos exigences. Source : [GitLab, Audit event schema and examples](https://docs.gitlab.com/user/compliance/audit_event_schema/).

• Activité d’authentification réussie et échouée
• Changements d’utilisateurs, de groupes, de rôles et d’autorisations
• Création, mise à jour et suppression d’enregistrements sensibles ou réglementés, lorsque requis
• Accès aux enregistrements ou utilisation de ceux-ci lorsque la politique ou le risque l’exige
• Exportations, téléchargements, importations, modifications en masse et actions de partage
• Changements de configuration administrative
• Changements d’intégrations, de jetons API, de webhooks ou de connecteurs
• Actions administratives réalisées via les interfaces utilisateur et les API, lorsque cela s’applique

Vérifiez la documentation, la configuration et le chemin de preuve

Une page de fonctionnalités d’un fournisseur ne suffit pas. Lisez la documentation officielle destinée aux administrateurs pour le modèle de déploiement précis que vous envisagez, puis vérifiez les paramètres par défaut et les enregistrements résultants dans un essai. Considérez toute inconnue comme une lacune jusqu’à ce que la documentation du fournisseur ou vos tests la résolvent.

Établissez d’abord la couverture des événements. Quelles actions créent des événements ? Les actions réussies comme les actions échouées sont-elles enregistrées lorsque nécessaire ? Les actions des utilisateurs ordinaires, les actions administratives et les actions par API sont-elles couvertes séparément ? Les catégories d’événements peuvent-elles être activées ou désactivées ?

Examinez ensuite la qualité des enregistrements. Déterminez si l’enregistrement identifie l’acteur de façon cohérente, indique un horodatage non ambigu et un fuseau horaire ou une norme de temps, identifie l’entité concernée, capture le type d’action et son résultat, et comprend un identifiant unique ou des informations de corrélation. Déterminez également comment le système représente les comptes de service, l’automatisation et l’activité anonyme. Un événement attribué uniquement à « API » ou « système » peut être insuffisant pour établir la responsabilité, sauf s’il peut être corrélé à une source d’identité plus fiable.

Vérifiez ensuite le comportement de récupération et de cycle de vie. Contrôlez les champs interrogeables, les filtres, la pagination, les formats d’export, l’accès par API et toute capacité de diffusion d’événements. GitLab documente le filtrage par acteur et plage de dates, mais indique que la recherche textuelle dans les détails des événements d’audit n’est pas prise en charge dans son interface ; il recommande une diffusion externe pour une recherche et une analyse complètes. C’est pourquoi « consultable dans l’interface » et « recherche prête pour une enquête » doivent figurer sur des lignes distinctes de la fiche d’évaluation. Source : [GitLab, Audit events](https://docs.gitlab.com/user/compliance/audit_events/).

Enfin, évaluez la protection. Le contrôle AU-9 du NIST considère la protection des informations d’audit et des outils de journalisation d’audit contre l’accès, la modification et la suppression non autorisés comme un objectif distinct. Un journal qu’un administrateur ordinaire peut modifier ou effacer silencieusement ne devient pas immuable du seul fait de son existence. Source : [NIST SP 800-53, contrôle AU-9](https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf).

• Couverture : quelles actions requises sont enregistrées, et lesquelles ne le sont pas ?
• Acteur : l’utilisateur humain, le compte de service ou l’administrateur est-il identifié de manière fiable ?
• Temps : existe-t-il une heure précise de l’événement, et les enregistrements peuvent-ils être corrélés entre les systèmes ?
• Objet : l’enregistrement identifie-t-il la fiche, le compte, le paramètre ou l’entité concerné ?
• Résultat et détails : enregistre-t-il la réussite, l’échec et suffisamment de contexte pour comprendre l’action ?
• Recherche : les examinateurs peuvent-ils filtrer par acteur, objet, type d’événement et plage horaire ? Le texte détaillé est-il interrogeable si nécessaire ?
• Export : les enregistrements peuvent-ils être exportés ou récupérés via une interface prise en charge dans un format utile ?
• Conservation : le stockage est-il activé, pendant combien de temps les événements sont-ils conservés et qui peut les modifier ou les effacer ? La protection : qui peut lire, modifier ou supprimer les enregistrements, et quelles garanties indépendantes existent ?