Bonnes pratiques à suivre pour des modèles sécurisés
L'une des dimensions les plus critiques du développement d'un modèle dans ThingWorx concerne sa sécurisation, de sorte que l'accès aux actifs du modèle s'effectue de manière contrôlée et que les implications en termes de sécurité soient dûment prises en compte à tous les niveaux. La gestion de la sécurité sur l'Edge est un aspect important de ce processus. Dans ThingWorx, vous devez configurer des autorisations granulaires sur les objets distants :
• en créant des utilisateurs uniques représentant les objets distants ;
• en affectant les utilisateurs à l'organisation appropriée ;
• en créant des clés d'application uniques dans le contexte utilisateur unique.
 |
Si vous utilisez la fonctionnalité de
chargement de fichier dans votre application, sachez qu'elle permet aux utilisateurs disposant des droits d'accès appropriés de charger sur le système tout type de contenu de fichier. PTC ne garantit pas que les fichiers chargés sont fiables et qu'ils proviennent d'un utilisateur de confiance.
|
La présente rubrique vous alerte sur les erreurs à éviter lors de la configuration de la sécurité d'un modèle et souligne les bonnes pratiques à suivre pour le rendre aussi sûr que possible.
Gestion de la sécurité sur l'Edge
La gestion de la sécurité sur l'Edge est une dimension importante de la sécurisation d'un modèle, qui entre en scène dès la construction du modèle et s'exprime ensuite par des déploiements sécurisés. L'Edge est une frontière entre l'environnement de modélisation de ThingWorx (Composer) et les sources de données externes. ThingWorx propose un certain nombre de mécanismes efficaces pour la gestion de la sécurité sur l'Edge, notamment l'utilisation des communications TLS/SSL pour les échanges entre l'Edge et la plateforme. L'utilisation de TLS/SSL donne les résultats suivants :
◦ Les objets distants valident le serveur au moyen de certificats.
◦ Le trafic est chiffré en TLS.
◦ Les clés d'application authentifient les objets distants sur la plateforme et le contexte utilisateur associé à la clé d'application limite l'accès à la plateforme.
Pratiques à éviter
Si des moyens existent pour rendre l'Edge aussi sûr que possible, certaines pratiques peuvent nuire à la sécurité globale du système, notamment les suivantes :
• Désactivation de SSL : déconseillé. Certains réseaux, y compris cellulaires, ont connu des failles dans leur architecture de sécurité.
• Utilisation de certificats avec des hashs vulnérables connus.
◦ Evitez MD5, SHA1, etc. Fiez-vous aux recommandations du NIST.
◦ N'utilisez pas de certificats auto-signés hors développement.
• Utilisation de la même clé d'application pour plusieurs périphériques. Les connexions sont authentifiées à l'aide de clés d'application. Si les clés d'application ne sont pas uniques sur tous les périphériques, il sera difficile d'auditer les connexions usurpées ou malveillantes.
• Utilisation de clés d'application avec des autorisations trop générales. Cette pratique risquerait de rendre à tort accessibles des actifs.
Pratiques recommandées
• Utilisez une autorité de certification approuvée.
• Mettez en oeuvre une authentification par certificat client : authentification TLS mutuelle.
|
|
Votre intégrateur système est responsable de l'implémentation de cette technologie. Pour tous les détails de l'implémentation, reportez-vous au manuel anglais
C SDK Users Guide (Guide d'utilisation du SDK C).
|
• Utilisez des clés d'application. Lors de la configuration des clés d'application et des utilisateurs de ThingWorx, accordez le moins de privilèges possible. Il n'est pas recommandé d'affecter un membre du groupe Administrateur à une clé d'application.
Configuration de votre modèle
Pour sécuriser totalement votre application, nous vous recommandons dans tous les cas d'appliquer les règles suivantes :
• Accordez le minimum de privilèges.
• Implémentez une défense en profondeur.
• Sécurisez les paramètres par défaut.
1. Configurez vos organisations.
La première étape de la création d'un modèle sécurisé pour vos périphériques Edge consiste à définir correctement la visibilité des entités au moyen d'
organisations. Les organisations fournissent des paramètres de visibilité à l'échelle du système pour les utilisateurs disposant d'un accès approprié à votre application.
2. Configurez vos groupes d'utilisateurs.
Configurez des groupes d'utilisateurs dans le but d'implémenter des contrôles d'accès basés sur les rôles utilisateur.
|
|
ThingWorx propose plusieurs groupes d'utilisateurs prédéfinis. Pour en savoir plus, consultez la rubrique
Groupes d'utilisateurs.
|
3. Configurez vos utilisateurs.
Les
Utilisateurs fournissent un accès granulaire aux données. Une fois vos organisations et groupes d'utilisateurs configurés, un utilisateur doit être créé pour chaque entité unique autorisée sur la plateforme. Du point de vue de l'Edge, cela signifie que vous devez créer un utilisateur pour chaque périphérique Edge qui sera connecté à la plateforme.
4. Configurez vos clés d'application.
Les
clés d'application sont utilisées pour accéder de façon sécurisée à la plateforme et sont liées à un contexte utilisateur pour la détermination des autorisations. Une clé d'application doit être créée pour chaque périphérique Edge qui sera connecté. Un ratio de 1:1 doit être respecté pour les clés d'application, les utilisateurs et les périphériques.
5. Configurez vos objets distants : visibilité, autorisations à la conception et à l'exécution
Une fois votre objet distant créé, le premier contexte de sécurité à définir est sa
visibilité. La visibilité concerne les organisations et les unités d'organisation.
Ensuite, définissez les autorisations de conception. De telles autorisations ne doivent être accordées qu'aux utilisateurs de confiance habilités à modifier le comportement et le modèle dans l'application. Habituellement, cela signifie qu'aucune autorisation de conception ne sera accordée aux utilisateurs/périphériques, étant donné qu'un périphérique ne doit pas pouvoir modifier son propre comportement.
Enfin, définissez des autorisations d'exécution de l'utilisateur qui représente le périphérique afin que celui-ci puisse contribuer sur le plan fonctionnel à l'application. Les autorisations d'exécution sont importantes pour la granularité. Au minimum, configurez les autorisations d'exécution de sorte que l'utilisateur puisse au moins accéder à l'objet. Si nécessaire, une plus grande granularité peut être définie sur les propriétés.
Conseils supplémentaires pour configurer votre modèle
• Il est recommandé de supprimer toutes les autorisations de conception dans l'environnement de production, et ce afin d'éviter d'éventuelles régressions dans les applications stratégiques. Il est préférable que toute la conception soit implémentée et validée dans une sandbox, et qu'elle ne soit déployée dans l'environnement de production qu'après validation de l'application.
• Les utilisateurs, les clés d'application et les objets distants peuvent être créés par programmation, mais tous les services créés pour implémenter cette fonctionnalité doivent être étroitement contrôlés dans le modèle de sécurité de l'application et respecter les exigences décrites dans la section précédente.
• Dès lors que deux objets Edge se connectent via le même EMS ou SDK, il n'est pas possible d'attribuer une clé d'application unique à chaque objet Edge. Si chacun de ces périphériques doit posséder un modèle d'autorisation distinct, il est recommandé qu'ils se connectent via des SDK distincts afin que des contextes de sécurité distincts soient disponibles pour chaque point de terminaison de connexion.
• Dès lors que des applications nécessitent plusieurs sources de données par objet distant ou que plusieurs utilisateurs accèdent à différents éléments d'un même objet à partir d'une application composite, des autorisations d'exécution peuvent être définies sur des propriétés et des services particuliers.
• Lorsque vous utilisez une entité de type
stockage de données (wikis, blogs, tables de données, flux et flux de valeurs), il est recommandé de fournir des autorisations d'exécution de service au service GetDefaultDataPersistenceProviderName du
Sous-système de plateforme. Un utilisateur doit disposer de droits de visibilité sur au moins un fournisseur de persistance du système pour pouvoir créer de nouveaux objets de type stockage de données.