Best practice per la modellazione sicura
La configurazione di un modello sicuro in ThingWorx è uno dei passi più critici nello sviluppo del modello per garantire che gli utenti dispongano dell'accesso corretto agli asset nel modello e che le implicazioni sulla sicurezza siano prese in considerazione in ogni fase. La gestione della sicurezza di edge è un aspetto importante di questo processo. In ThingWorx è necessario impostare permessi granulari su oggetti remoti eseguendo le operazioni indicate di seguito.
• Creare utenti univoci che rappresentano gli oggetti remoti
• Assegnare gli utenti all'organizzazione corretta
• Creare chiavi di accesso univoche nel contesto utente univoco
 |
Se si utilizza la funzionalità di caricamento file nell'applicazione, tenere presente che il caricamento di file consente agli utenti con accesso appropriato di caricare qualsiasi tipo di contenuto di file nel sistema. PTC non garantisce che i file caricati siano sicuri e che l'input provenga da un utente attendibile.
|
Le informazioni contenute in questo argomento hanno lo scopo di fornire suggerimenti sulle pratiche da evitare quando si imposta la sicurezza nel modello, nonché le best practice per impostare il modello nel modo più sicuro possibile.
Gestione della sicurezza di edge
Gestire la sicurezza di edge è un aspetto importante per proteggere un modello, iniziando dalla creazione del modello fino alle implementazioni sicure. L'edge è una barriera tra l'ambiente di modellazione in ThingWorx (Composer) e le origini dati esterne. In ThingWorx, la sicurezza a livello di edge viene gestita in molti modi, tra cui l'utilizzo di comunicazioni TLS/SSL tra l'edge e la piattaforma. Utilizzando TLS/SSL, si verifica quanto riportato di seguito.
◦ Gli oggetti remoti convalidano il server con i certificati.
◦ Il traffico viene crittografato utilizzando TLS.
◦ Le chiavi di accesso autenticano gli oggetti remoti sulla piattaforma e il contesto utente associato alla chiave di accesso limita l'accesso all'interno della piattaforma.
Pratiche da evitare
Sebbene sia possibile adottare alcune misure per rendere l'edge il più sicuro possibile, alcune procedure possono compromettere la sicurezza generale del sistema. Tali procedure comprendono quelle illustrate di seguito.
• La disattivazione di SSL non è consigliata. Anche sui cellulari alcune reti presentano difetti noti nell'architettura di sicurezza.
• Utilizzo di certificati con hash vulnerabili noti.
◦ Non utilizzare MD5, SHA1 e così via. Utilizzare funzioni consigliate da NIST.
◦ Non utilizzare certificati autofirmati al di fuori dello sviluppo.
• Utilizzo della stessa chiave di accesso per più dispositivi. Le connessioni vengono autenticate utilizzando le chiavi di accesso. Se le chiavi di accesso non sono univoche tra i dispositivi, sarà difficile verificare le connessioni impersonate o dannose.
• Utilizzo delle chiavi di accesso con autorizzazioni ampie. Ciò può comportare l'accesso ad asset a cui non si dovrebbe accedere.
Pratiche da usare
• Utilizzare un'autorità di certificazione attendibile.
• Utilizzare l'autorizzazione del certificato client - TLS reciproco.
|
|
L'integratore di sistema è responsabile dell'implementazione di questa tecnologia. Per dettagli sull'implementazione, fare riferimento a C SDK Users Guide.
|
• Utilizzo delle chiavi di accesso. Quando si impostano le chiavi di accesso e gli utenti ThingWorx, si consiglia di concedere sempre privilegi minimi. Non è consigliabile assegnare un membro del gruppo Amministratori a una chiave di accesso.
Impostazione del modello
Per proteggere completamente l'applicazione, è sempre consigliabile adottare le best practice riportate di seguito.
• Concedere privilegi minimi
• Adottare un approccio di difesa in profondità
• Proteggere le impostazioni di default
1. Configurare le organizzazioni
Il primo passo per creare un modello sicuro per i dispositivi edge consiste nell'impostare correttamente la visibilità delle entità che utilizzano un'organizzazione. Le organizzazioni possono fornire impostazioni di visibilità a livello di sistema per gli utenti con un accesso appropriato all'applicazione.
2. Configurare gruppi utenti
Creare gruppi utenti per sviluppare controlli di accesso basati sui ruoli utente.
|
|
ThingWorx fornisce diversi gruppi utenti predefiniti. Per ulteriori informazioni, vedere la sezione Gruppi utenti.
|
3. Configurare gli utenti
Gli utenti forniscono accesso granulare ai dati. Dopo aver configurato organizzazioni e gruppi utenti, è necessario creare un utente per ogni entità consentita in modo univoco sulla piattaforma. Dal punto di vista di edge, ciò significa creare un utente per ciascun dispositivo edge che sarà connesso alla piattaforma.
4. Configurare le chiavi di accesso
Le chiavi di accesso sono utilizzate per accedere in modo sicuro alla piattaforma e vengono collegate a un contesto utente per determinare i permessi. Deve essere creata una chiave di accesso per ogni dispositivo edge che verrà collegato. Il rapporto per le chiavi di accesso, gli utenti e i dispositivi deve essere 1:1.
5. Configurare gli oggetti remoti: visibilità, permessi per le fasi di progettazione e di esecuzione
Dopo aver creato l'oggetto remoto, il primo contesto di sicurezza da impostare è la visibilità. La visibilità influenza le organizzazioni e le unità organizzative.
Impostare, quindi, i permessi per la fase di progettazione. I permessi per la fase di progettazione devono essere concessi solo agli utenti fidati che devono modificare il comportamento e il modello all'interno dell'applicazione. In genere, ciò significa che l'utente/il dispositivo non avrà il permesso per la fase di progettazione, poiché il dispositivo non deve essere in grado di modificare il proprio comportamento.
Infine, impostare i permessi per la fase di esecuzione per l'utente che rappresenta il dispositivo in modo che il dispositivo possa contribuire in modo funzionale all'applicazione. I permessi per la fase di esecuzione sono importanti per la granularità. Impostare come minimo i permessi per la fase di esecuzione in modo che l'utente possa accedere solo all'oggetto. Se necessario, è possibile impostare maggiore granularità sulle proprietà.
Ulteriori suggerimenti per l'impostazione del modello
• La best practice prevede di rimuovere tutti i permessi per la fase di progettazione in un ambiente di produzione per evitare possibili regressioni in applicazioni business-critical. Tutta la progettazione deve essere implementata e convalidata all'interno di una sandbox e quindi distribuita in un ambiente di produzione solo dopo una corretta convalida dell'applicazione.
• Gli utenti, le chiavi di accesso e gli oggetti remoti possono essere creati a livello di codice, ma tutti i servizi creati per implementare questa funzionalità devono essere strettamente controllati nel modello di sicurezza dell'applicazione e rispettare le indicazioni descritte nella sezione precedente.
• Se sono presenti due oggetti edge che si connettono attraverso lo stesso EMS o SDK, non è possibile assegnare una chiave di accesso a ciascun oggetto edge. Se è necessario separare il modello di autorizzazione per questi dispositivi, si consiglia di collegarli tramite SDK separati per fornire contesti di sicurezza separati per ciascun endpoint di connessione.
• Se sono presenti applicazioni che richiedono più origini dati per oggetti remoti o se più utenti accedono a diverse origini dati dello stesso oggetto da un mashup, è possibile impostare i permessi della fase di esecuzione su proprietà e servizi singoli.
• Quando si utilizza un'entità di tipo archiviazione dati (wiki, blog, tabelle dati, stream e stream di valori), si consiglia di fornire i permessi di esecuzione del servizio al servizio del Sottosistema PiattaformaGetDefaultDataPersistenceProviderName. Un utente deve avere la visibilità di almeno un provider di persistenza nel sistema per creare nuovi oggetti del tipo archiviazione dati.
|
|
Il controllo del permesso di visibilità può essere attivato nell'istanza di RemoteThing. In questo modo è possibile verificare se l'utente della chiave di accesso utilizzato per associare il dispositivo edge dispone dei permessi di visibilità per l'oggetto remoto. Per ulteriori informazioni, vedere Configurazione dei permessi di visibilità per l'oggetto RemoteThing.
|