Sottosistema Verifica
Il sottosistema Verifica fornisce una funzionalità di verifica incorporata per gli amministratori di sistema, gli amministratori di applicazione e i revisori della soluzione IoT di un'organizzazione. Per default è disattivato all'avvio della piattaforma ed è necessario attivarlo.
Il sottosistema Verifica ha lo scopo di fornire le informazioni necessarie per rispondere alle domande seguenti.
• I requisiti di conformità sono soddisfatti?
• Che cosa ha fatto un dipendente disonesto nel sistema?
• Chi ha apportato quali modifiche e quando?
 |
È importante ricordare che il log verifiche non è un altro log di debug. Il log verifiche fornisce le informazioni relative a chi ha apportato quali modifiche quando e qualsiasi altra informazione che potrebbe essere necessario acquisire per motivi di conformità.
|
La release iniziale del sottosistema Verifica faceva parte di ThingWorx Platform 8.2.0. Questa versione viene definita implementazione della tabella dati. A partire da ThingWorx Platform 9.0.0, per il sottosistema Verifica è disponibile anche un'altra implementazione, definita implementazione della persistenza diretta. L'implementazione della persistenza diretta è un'implementazione completamente nuova che fornisce uno strumento di verifica più solido e performante. Per la compatibilità con le versioni precedenti, l'implementazione della tabella dati è l'implementazione di default utilizzata quando si attiva il sottosistema Verifica. È possibile passare all'implementazione della persistenza diretta durante la configurazione del sottosistema Verifica.
|
|
PTC consiglia vivamente di utilizzare l'implementazione della persistenza diretta in quanto l'implementazione della tabella dati viene contrassegnata come obsoleta in una release futura di ThingWorx Platform. Inoltre il servizio QueryAuditHistory viene contrassegnato come obsoleto a favore del servizio QueryAuditHistoryWithQueryCriteria.
|
Se in precedenza si è utilizzata l'implementazione della tabella dati, i dati vengono mantenuti quando si esegue un aggiornamento. Dopo l'aggiornamento si consiglia di archiviare tutti i dati di verifica online prima di passare all'implementazione della persistenza diretta.
Nelle sezioni riportate di seguito vengono fornite informazioni dettagliate sulle attività sottoposte a verifica e sulle funzionalità del sottosistema Verifica per le due implementazioni. Fare clic sul titolo di una sezione per visualizzarne il contenuto. Per nascondere il contenuto, fare nuovamente clic sul titolo.
Funzionalità del sottosistema Verifica: implementazione della tabella dati
L'implementazione della tabella dati supporta le funzionalità di verifica seguenti.
• Ricerca delle voci di verifica
• Archiviazione delle voci di verifica online nello spazio di archiviazione non in linea
• Esportazione dei dati di verifica online e non in linea, utilizzando la lingua selezionata per l'esportazione
• Eliminazione dei dati di verifica online e pulizia dei dati di verifica archiviati (non in linea)
Quando il sottosistema Verifica è attivato ed è selezionata l'opzione Avvio automatico, il sottosistema si avvia quando si avvia ThingWorx Platform e si arresta quando si arresta la piattaforma.
A partire dalla versione 8.5 di ThingWorx Platform, il sottosistema esegue la verifica del passaggio del contesto di protezione da un utente a un altro nonché dell'elevazione del contesto di protezione a Super User. Per ulteriori informazioni, fare riferimento a Verifica del cambiamento del contesto di protezione .
 | Per le organizzazioni che devono raccogliere e mantenere grandi quantità di dati di verifica, l'implementazione della persistenza diretta è fortemente consigliata per prestazioni ottimali e funzionalità aggiuntive. Per default, il sottosistema Verifica è disattivato in caso di nuova installazione o aggiornamento. Inoltre è attivata l'implementazione della tabella dati ed è disattivata l'implementazione della persistenza diretta. Se l'utente è un amministratore di sistema e ha attivato il sottosistema Verifica, è possibile modificare la configurazione del sottosistema Verifica per passare dall'implementazione della tabella dati all'implementazione della persistenza diretta. Fare riferimento a Configurazione del sottosistema Verifica. |
Sottosistema Verifica in ThingWorx Platform: persistenza diretta
L'implementazione della persistenza diretta fornisce tutte le funzionalità di verifica dell'implementazione della tabella dati e altro ancora. Con l'aggiunta di questa implementazione in ThingWorx Platform 9.0.0, il sottosistema Verifica presenta modifiche significative che offrono i miglioramenti seguenti in termini di prestazioni e scalabilità.
• La persistenza dei dati di verifica utilizza il provider di persistenza di ThingWorx Platform. Questa implementazione può essere utilizzata con database PostgreSQL o MSSQL utilizzati come provider di persistenza per le istanze di ThingWorx Platform.
 | Non è possibile modificare la configurazione del provider di persistenza della piattaforma tramite la pagina Configurazione del sottosistema Verifica. |
• L'interrogazione è più performante.
• L'interrogazione può essere configurata in base alle esigenze e ai casi di utilizzo di organizzazioni diverse. I servizi di interrogazione accettano i token di localizzazione per il parametro di categoria di un'interrogazione.
L'utilizzo di un database nell'implementazione della persistenza diretta migliora la funzionalità di interrogazione. Oltre al filtraggio e all'ordinamento disponibili nell'implementazione della tabella dati è possibile specificare le proprietà di impaginazione quando si utilizzano i servizi QueryAuditHistory e QueryAuditDataWithQueryCriteria con l'implementazione della persistenza diretta.
| | I servizi QueryAuditHistory e QueryAuditHistoryWithQueryCriteria non eseguono alcun controllo di visibilità. Tutto è visibile agli utenti che dispongono dei permessi per eseguire il servizio. È possibile eseguire un servizio di interrogazione direttamente dalla pagina Servizi del sottosistema Verifica. È inoltre possibile eseguire un'interrogazione indirettamente utilizzando il log verifiche, disponibile tramite Monitoraggio nell'interfaccia utente di ThingWorx Composer. Gli utenti con i permessi di accesso appropriati possono eseguire il servizio manualmente da ThingWorx Composer. Gli sviluppatori possono utilizzare le API REST di ThingWorx per eseguire il servizio a livello di programmazione. |
• Un altro servizio QueryAuditHistory è disponibile a livello di oggetto. Questo servizio limita i dati sottoposti a interrogazione solo all'oggetto e all'utente correnti. Se l'utente che esegue questo servizio si trova nel gruppo Auditors, può visualizzare le azioni di tutti gli altri utenti ma solo per quell'oggetto.
| | A partire da ThingWorx Platform 9.0.0 è disponibile il gruppo di utenti Auditors. |
• Oltre al servizio ExportAuditData, l'implementazione della persistenza diretta fornisce il servizio ExportOnlineAuditData. Per informazioni dettagliate su questo servizio, fare riferimento a Esportazione dei dati di verifica online.
• L'implementazione della persistenza diretta fornisce inoltre un'opzione di archiviazione meno costosa rispetto all'implementazione della tabella dati con il servizio ArchiveAuditHistoryDirectPersistence[DATETIME[). Questo servizio copia le voci di verifica dal database ThingWorx in un file all'interno del repository di file configurato per i dati di verifica, nella cartella AuditArchiveDirectPersistence.
• Il sottosistema Verifica può supportare i clienti che hanno esigenze più o meno complesse in termini di dati di verifica. Per la configurazione del sottosistema viene fornita una guida in base a specifiche esigenze di conservazione dei dati. Fare riferimento a Configurazione del sottosistema Verifica.
• Per monitorare l'esecuzione dei servizi del sottosistema Verifica, viene fornita una categoria denominata AUDIT.
• Il sottosistema comprende ulteriori messaggi di verifica per le categorie. Per ulteriori informazioni sui messaggi di verifica per l'implementazione della persistenza diretta, fare riferimento a Messaggi di verifica ThingWorx.
• Se l'insieme di categorie di verifica fornito nel sottosistema non soddisfa tutti i requisiti dell'organizzazione, gli sviluppatori possono creare categorie e messaggi di verifica personalizzati. Fare riferimento a Categorie di verifica personalizzate .
• SOLO BETA: l'implementazione della persistenza diretta migliora inoltre la facilità di utilizzo del sottosistema Verifica fornendo una nuova interfaccia utente all'interno di ThingWorx Composer per l'interrogazione dei dati di verifica. Disponibile sotto forma di scheda nella sezione Monitoraggio di Composer, questa nuova interfaccia utente fornisce opzioni di filtro per le interrogazioni e opzioni di impaginazione per i risultati dell'interrogazione.
I log verifiche possono contenere dati sensibili. Per garantire l'integrità dei dati di verifica, assicurarsi di limitare l'accesso utilizzando le funzionalità dei permessi di ThingWorx. Per ulteriori informazioni, fare riferimento a Protezione per attività di verifica.
Di quali attività viene eseguita la verifica?
Entrambe le implementazioni monitorano ThingWorx Platform per gli eventi generati da vari componenti ed estensioni. Le attività come il trasferimento di file mediante il sottosistema Trasferimento file della piattaforma possono generare eventi. Si può effettuare la sottoscrizione a tali eventi, usandoli per attivare altre azioni.
La funzionalità di verifica esiste per i tipi di eventi incorporati in ThingWorx seguenti.
• Eventi correlati agli oggetti - FileTransfer e RemoteSession
| | L'evento ThingStart è disattivato per default a partire da ThingWorx Platform 9.0.0. Per attivarlo, modificare il file di configurazione platform-settings.json. Se attivato, l'evento viene sottoposto a verifica. |
• Eventi di monitoraggio di protezione - LoginSucceeded, LoginFailed, ApplicationKeySucceeded e ApplicationKeyFailed. Viene sottoposto a verifica anche il cambiamento del contesto di protezione.
| | Gli eventi ApplicationKeySucceeded e ApplicationKeyFailed vengono attivati solo per le connessioni REST HTTP/HTTPS. |
• Eventi del sottosistema - Vengono sottoposti a verifica gli aggiornamenti della configurazione di un sottosistema. Inoltre le chiamate ai servizi di verifica quali l'archiviazione, l'esportazione, la pulizia e l'eliminazione vengono sottoposte a verifica nella categoria AUDIT.
| | Le azioni di avvio, arresto e riavvio dei sottosistemi non vengono sottoposte a verifica. |
In genere gli eventi seguenti vengono attivati da un'operazione su un'entità in ThingWorx.
• Gli eventi correlati agli oggetti vengono attivati da operazioni che possono essere eseguite su oggetti, come il trasferimento di file tramite il sottosistema Trasferimento file e il tunneling (evento RemoteSession).
• Gli eventi di monitoraggio della protezione sono per gli utenti che accedono a ThingWorx.
Personalizzazione della funzionalità Verifica
La funzionalità di verifica personalizzata include i seguenti componenti:
• Categoria di verifica personalizzata
• Messaggio di verifica personalizzato
• Evento di verifica personalizzato
Esistono due modi per creare una categoria di verifica personalizzata e un token del messaggio di verifica personalizzato:
• Creando una nuova estensione Java back-end per la piattaforma, utilizzando ThingWorx Java SDK. Fare riferimento a Creazione di categorie di verifica personalizzate mediante un'estensione. L'estensione deve includere una tabella di localizzazione in modo che, importando l'estensione in ThingWorx Platform, venga importata anche la tabella di localizzazione con il token della categoria di verifica e il token del messaggio di verifica.
• Per una categoria di verifica personalizzata, modificando la tabella di localizzazione ThingWorx tramite ThingWorx Composer. Fare riferimento a Categorie di verifica personalizzate .
Gli eventi di verifica personalizzati devono essere definiti nel codice dell'estensione perché sono necessari due aspetti. Questi aspetti non sono esposti nell'interfaccia utente di Composer, pertanto non è possibile aggiungere un evento personalizzato da Composer. Questi aspetti indicano alla piattaforma che l'evento deve essere sottoposto a verifica. La figura riportata di seguito evidenzia questi due aspetti:
