Sous-système d'audit
Le sous-système d'audit fournit une fonctionnalité d'audit intégrée pour les administrateurs système, les administrateurs d'applications et les auditeurs de la solution IoT.
Pour garantir l'intégrité des données d'audit, les journaux ne sont pas modifiables. En outre, les journaux d'audit ne contiennent aucune donnée sensible.
Lorsque cette option est activée et que l'option Démarrage automatique est sélectionnée, le sous-système d'audit démarre lorsque ThingWorx Platform démarre et s'arrête lorsque l'instance est arrêtée. Il prend en charge les fonctionnalités d'audit suivantes :
• Recherche d'entrées d'audit (à l'aide du service QueryAuditHistory)
• Archivage des entrées d'audit sur le stockage hors ligne (réalisé automatiquement quotidiennement par défaut)
• Exportation des données d'audit, en utilisant la langue sélectionnée pour l'exportation
• Purge des données d'audit en ligne une fois atteint l'un des seuils définis dans la configuration du sous-système d'audit, à savoir le nombre maximal de jours de conservation des données d'audit en ligne ou le nombre maximal de lignes pouvant être conservées en ligne.
• Audit des actions de démarrage, d'arrêt et de redémarrage
• A compter de la version 8.5 de ThingWorx Platform, le sous-système d'audit contrôle le changement du contexte de sécurité d'un utilisateur à un autre, ainsi que l'élévation du contexte de sécurité pour un super utilisateur. Pour plus d'informations, consultez la rubrique
Audit du changement de contexte de sécurité .
 |
Par défaut, le sous-système d'audit est désactivé dans une nouvelle installation ou une mise à niveau. Si vous êtes administrateur système, consultez la rubrique
Activation du sous-système d'audit pour découvrir comment activer le sous-système.
|
Quelles activités font l'objet d'un audit ?
Des activités sur ThingWorx Platform peuvent générer des événements. Par exemple, le lancement d'un téléchargement de fichier génère un événement. Vous souhaiterez peut-être vous abonner à ces événements, afin de les utiliser pour déclencher d'autres actions. Dans ThingWorx, vous pouvez auditer les types suivants d'événements intégrés :
• Evénements orientés objet : ThingStart, FileTransfer et RemoteSession.
• Evénements de contrôle de sécurité : LoginSucceeded, LoginFailed, ApplicationKeySucceeded et ApplicationKeyFailed
• Evénements de sous-systèmes : à compter de la version 8.5.0 de ThingWorx Platform, les actions de démarrage, d'arrêt et de redémarrage sur les sous-systèmes sont auditées. Notez que les actions de redémarrage affichent un message d'audit de redémarrage et les messages d'audit de démarrage/d'arrêt dans le journal d'audit.
|
|
Les événements ApplicationKeySucceeded et ApplicationKeyFailed sont déclenchés uniquement pour les connexions HTTP/HTTPS REST.
|
En général, ces événements sont déclenchés par une opération appliquée à une entité dans ThingWorx :
• Les événements orientés objet sont déclenchés par des opérations pouvant être effectuées sur des objets, notamment le démarrage ou redémarrage d'un objet, le transfert de fichiers via le sous-système de gestion des transferts de fichiers et la tunnellisation (événement RemoteSession).
• Les événements de contrôle de sécurité sont destinés aux utilisateurs qui accèdent à ThingWorx.
• Les événements de sous-systèmes sont déclenchés lors du démarrage, de l'arrêt ou du redémarrage d'un sous-système.
|
|
L'audit des événements définis par l'utilisateur (personnalisés) n'est pas pris en charge.
|
En fonction de son statut, lorsqu'un sous-système est redémarré, deux ou trois messages d'audit sont insérés. Prenons les exemples suivants :
• Scénario : si le statut du sous-système est RUNNING, l'opération Restart insère trois messages :
◦ System Subsystem "FederationSubsystem" restarted
◦ System Subsystem "FederationSubsystem" stopped
◦ System Subsystem "Federation Subsystem" started
• Scénario : si le statut actuel du sous-système n'est pas RUNNING, l'opération Restart n'insère que deux messages car l'opération Stop n'est pas effectuée :
◦ System Subsystem "FederationSubsystem" restarted
◦ System Subsystem "Federation Subsystem" started
Audit du changement de contexte de sécurité
A compter de la version 8.5 de ThingWorx Platform, le sous-système d'audit contrôle le changement du contexte de sécurité d'un utilisateur à un autre, ainsi que l'élévation du contexte de sécurité pour un super utilisateur. Un exemple de changement de contexte de sécurité se produit lors de l'appel de la méthode SecurityContext.createUserContext(User anotherUser) de l'API d'extension ThingWorx. Cette méthode permet à une extension ou à un script de basculer vers le contexte de sécurité d'un autre utilisateur. La méthode SecurityContext.createSuperUserContext() de l'API d'extension ThingWorx permet à une extension ou à un script de basculer vers le contexte de sécurité du super utilisateur du système, le code d'extension ayant alors accès à toutes les entités auxquelles un super utilisateur peut accéder.
Le changement de contexte de sécurité se produit souvent en interne dans ThingWorx Platform pour permettre à différentes fonctions d'accéder aux services et aux entités qui ne sont pas forcément visibles par les utilisateurs standard. C'est pourquoi tous les changements de contexte de sécurité ne sont pas audités. Seuls les changements de contexte de sécurité délibérés pouvant indiquer une violation de sécurité sont auditées.
La catégorie de ces messages est SECURITY_CONFIGURATION.
Les messages d'audit liés à un changement de contexte de sécurité sont les suivants :
audit.securityContext.SuperUser
User _currentUser__switched context to SuperUser within the Entity Context of __thingName__.
audit.SecurityContext.Changed
User __currentUser__ switched context to __username__within the Entity Context of __thingName__.
User _currentUser__switched context to SuperUser within the Entity Context of __thingName__.
audit.SecurityContext.Changed
User __currentUser__ switched context to __username__within the Entity Context of __thingName__.