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 d'une organisation. Par défaut, il est désactivé au démarrage de la plateforme. Vous devez l'activer.
Le sous-système d'audit est conçu pour vous fournir les informations dont vous avez besoin pour répondre aux questions suivantes :
• Les exigences de conformité sont-elles respectées ?
• Quelles actions un employé malveillant a-t-il effectué dans le système ?
• Qui a apporté des modifications et quand ?
 |
N'oubliez pas : le journal d'audit n'est pas un simple journal de débogage. Il fournit des informations liées aux modifications (notamment leurs auteurs, leur teneur et la date) ainsi que d'autres informations qu'il peut être nécessaire de consigner à des fins de conformité.
|
La version initiale du sous-système d'audit faisait partie de ThingWorx Platform 8.2.0. Cette version est appelée Implémentation de type Table de données. Depuis ThingWorx Platform 9.0.0, une autre implémentation, appelée Implémentation de type Persistance directe, est également disponible pour le sous-système d'audit. L'implémentation de type Persistance directe est une toute nouvelle implémentation qui fournit un outil d'audit plus robuste et performant. A des fins de compatibilité descendante, l'implémentation de type Table de données est l'implémentation par défaut utilisée lorsque vous activez le sous-système d'audit. Vous pouvez passer à l'implémentation de type Persistance directe lors de la configuration du sous-système d'audit.
|
|
PTC vous encourage vivement à utiliser cette nouvelle implémentation, car l'implémentation de type Table de données sera désapprouvée dans une prochaine version de ThingWorx Platform. En outre, le service QueryAuditHistory sera également désapprouvé au profit du service QueryAuditHistoryWithQueryCriteria.
|
Si vous avez précédemment utilisé l'implémentation de type Table de données, vos données sont conservées lorsque vous effectuez une mise à niveau. A l'issue de la mise à niveau, il est recommandé d'archiver toutes les données d'audit en ligne avant de passer à l'implémentation de type Persistance directe.
Les sections suivantes fournissent des détails sur les activités auditées ainsi que les fonctionnalités du sous-système d'audit pour les deux implémentations. Cliquez sur le titre d'une section pour afficher son contenu. Pour masquer le contenu, cliquez à nouveau sur le titre.
Fonctionnalités du sous-système d'audit - Implémentation de type Table de données
L'implémentation de type Table de données prend en charge les fonctionnalités d'audit suivantes :
• Recherche d'entrées d'audit
• Archivage des entrées d'audit en ligne dans le stockage hors ligne
• Exportation des données d'audit en ligne et hors ligne, en utilisant la langue sélectionnée pour l'exportation
• Purge des données d'audit en ligne et nettoyage des données d'audit archivées (hors ligne)
Lorsque le sous-système d'audit est activé et que l'option Démarrage automatique est sélectionnée, le sous-système démarre lorsque ThingWorx Platform démarre et s'arrête lorsque la plateforme est arrêtée.
A compter de la version 8.5 de ThingWorx Platform, le sous-système 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 de détails, consultez la rubrique Audit du changement de contexte de sécurité .
 | Pour les organisations qui doivent collecter et conserver de grandes quantités de données d'audit, l'implémentation de type Persistance directe est vivement recommandée pour bénéficier de performances optimales et de fonctionnalités supplémentaires. Par défaut, le sous-système est désactivé dans une nouvelle installation ou une mise à niveau. En outre, l'implémentation de type Table de données est activée. Celle de type Persistance directe est désactivée. Si vous êtes administrateur système et que vous avez activé le sous-système d'audit, vous pouvez modifier la configuration du sous-système d'audit pour passer de l'implémentation de type Table de données à celle de type Persistance directe. Reportez-vous à la page Configuration du sous-système d'audit. |
Sous-système d'audit dans ThingWorx Platform - Persistance directe
L'implémentation de type Persistance directe fournit toutes les fonctionnalités d'audit de l'implémentation de type Table de données, et bien plus encore. Avec l'ajout de cette implémentation à ThingWorx Platform 9.0.0, le sous-système d'audit est modifié en profondeur et bénéficie des améliorations suivantes en matière de performances et d'évolutivité :
• La persistance des données d'audit utilise le fournisseur de persistance de ThingWorx Platform. Cette implémentation peut être utilisée avec des bases de données PostgreSQL ou MSSQL utilisées en tant que fournisseurs de persistance pour les instances de ThingWorx Platform.
 | Il n'est pas possible de modifier la configuration du fournisseur de persistance de la plateforme via la page de configuration du sous-système d'audit. |
• L'interrogation est plus performante.
• L'interrogation est configurable pour s'adapter aux besoins et aux cas d'utilisation de différentes organisations. Les services de requête acceptent les jetons de localisation pour le paramètre de catégorie d'une requête.
L'utilisation d'une base de données dans l'implémentation de type Persistance directe améliore la fonctionnalité d'interrogation. Outre le filtrage et le tri disponibles dans l'implémentation de type Table de données, vous pouvez spécifier des propriétés de pagination lorsque vous utilisez les services QueryAuditHistory et QueryAuditDataWithQueryCriteria avec l'implémentation de type Persistance directe.
| | Les services QueryAuditHistory et QueryAuditHistoryWithQueryCriteria et n'effectuent aucun contrôle de visibilité. Toutes les données sont visibles aux utilisateurs autorisés à exécuter ce service. Vous pouvez exécuter un service de requête directement à partir de la page Services du sous-système d'audit. Vous pouvez également exécuter une requête de manière indirecte à l'aide du journal d'audit, accessible via Surveillance dans l'interface utilisateur de ThingWorx Composer. Les utilisateurs disposant des droits d'accès appropriés peuvent exécuter le service manuellement à partir de ThingWorx Composer. Les développeurs peuvent utiliser les API REST ThingWorx pour exécuter le service par programmation. |
• Un autre service QueryAuditHistory est disponible au niveau de l'objet. Ce service limite les données interrogées à l'objet et à l'utilisateur actuels uniquement. Si l'utilisateur qui exécute ce service appartient au groupe Auditors, il peut afficher les actions de tous les autres utilisateurs, mais uniquement pour cet objet.
| | Le groupe d'utilisateurs Auditors est disponible depuis ThingWorx Platform 9.0.0. |
• Outre le service ExportAuditData, l'implémentation de type Persistance directe fournit le service ExportOnlineAuditData. Pour plus d'informations sur ce service, consultez la rubrique Exportation des données d'audit en ligne.
• L'implémentation de type Persistance directe fournit également une option de stockage moins coûteuse que l'implémentation de type Table de données avec le service ArchiveAuditHistoryDirectPersistence[DATETIME[). Ce service copie les entrées d'audit de la base de données ThingWorx dans un fichier du référentiel de fichiers configuré pour les données d'audit, dans le dossier AuditArchiveDirectPersistence.
• Le sous-système d'audit répond à tous les besoins des clients en matière de données d'audit. Vous trouverez des instructions sur la configuration du sous-système en fonction des besoins spécifiques de conservation des données. Consultez la rubrique Configuration du sous-système d'audit.
• Une catégorie de suivi de l'exécution des services du sous-système d'audit est fournie (AUDIT).
• Le sous-système propose des messages d'audit supplémentaires pour les catégories. Pour plus d'informations sur les messages d'audit relatifs à l'implémentation de type Persistance directe, consultez la rubrique Messages d'audit de ThingWorx.
• Si l'ensemble de catégories d'audit fournies dans le sous-système ne répond pas à toutes les exigences de votre organisation, les développeurs peuvent créer des catégories et des messages personnalisés. Consultez la section Catégories d'audit personnalisées .
• BETA UNIQUEMENT : l'implémentation de type Persistance directe améliore également l'utilisabilité du sous-système d'audit en fournissant une nouvelle interface utilisateur dans ThingWorx Composer pour l'interrogation des données d'audit. Disponible sous la forme d'un onglet dans la section Surveillance de Composer, cette nouvelle interface utilisateur fournit des options de filtrage pour les requêtes, ainsi que des options de pagination pour les résultats des requêtes.
Les journaux d'audit peuvent contenir des données sensibles. Pour garantir leur intégrité, assurez-vous de limiter l'accès à l'aide des autorisations ThingWorx. Pour plus de détails, consultez la rubrique Sécurité des activités d'audit.
Quelles activités font l'objet d'un audit ?
Les deux implémentations contrôlent les événements générés par différents composants et extensions dans ThingWorx Platform. Les activités telles que le transfert de fichiers à l'aide du sous-système de fichiers de la plateforme peuvent générer des événements. 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 : FileTransfer et RemoteSession
| | Depuis ThingWorx Platform 9.0.0, l'événement ThingStart est désactivé par défaut. Pour l'activer, modifiez le fichier de configuration platform-settings.json. S'il est activé, l'événement est audité. |
• Evénements de contrôle de sécurité : LoginSucceeded, LoginFailed, ApplicationKeySucceeded et ApplicationKeyFailed En outre, le changement du contexte de sécurité est audité.
| | Les événements ApplicationKeySucceeded et ApplicationKeyFailed sont déclenchés uniquement pour les connexions HTTP/HTTPS REST. |
• Evénements de sous-systèmes : les mises à jour apportées à la configuration d'un sous-système sont auditées. En outre, les appels à des services d'audit tels que l'archivage, l'exportation, le nettoyage et la purge, sont audités dans la catégorie AUDIT.
| | Les actions de démarrage, d'arrêt et de redémarrage sur les sous-systèmes ne sont pas auditées. |
En général, les événements suivants 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 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.
Personnalisation de la fonctionnalité d'audit
Pour personnaliser la fonctionnalité d'audit, vous définissez les trois types d'éléments suivants :
• Catégorie d'audit personnalisée
• Message d'audit personnalisé
• Evénement d'audit personnalisé
Vous pouvez procéder de deux manières différentes pour créer une catégorie d'audit personnalisée et un jeton de message d'audit personnalisé :
• En créant une nouvelle extension Java back-end pour la plateforme, à l'aide du SDK Java ThingWorx. Reportez-vous à la page Création de catégories d'audit personnalisées à l'aide d'une extension. L'extension doit inclure une table de localisation de sorte que, à l'importation de l'extension dans ThingWorx Platform, la table de localisation soit importée avec le jeton de catégorie d'audit et le jeton de message d'audit ajoutés.
• Pour une catégorie d'audit personnalisée, en modifiant la table de localisation ThingWorx à l'aide de ThingWorx Composer. Reportez-vous à la page Catégories d'audit personnalisées .
Les événements d'audit personnalisés doivent être définis dans le code de votre extension, car deux aspects sont requis. Comme ces aspects ne sont pas exposés dans l'interface utilisateur de Composer, vous ne pouvez pas ajouter d'événement personnalisé à partir de Composer. Ces aspects indiquent à la plateforme que l'événement doit être audité. La capture d'écran suivante vous montre ces deux aspects :
