Prácticas recomendadas del modelado seguro
La configuración de un modelo seguro en ThingWorx es uno de los pasos más críticos en el desarrollo de modelos para garantizar que los usuarios tengan el acceso correcto a los activos en el modelo y que se tengan en cuenta las implicaciones de seguridad para cada paso. La gestión de la seguridad del servidor Edge es un aspecto importante de este proceso. En ThingWorx, es necesario configurar permisos granulares en cosas remotas mediante las siguientes acciones:
• Creación de usuarios únicos que representen las cosas remotas
• Asignación de los usuarios a la organización correcta
• Creación de claves de aplicación únicas en el contexto de usuario exclusivo
 |
Si se utiliza la funcionalidad carga de fichero en la aplicación, se debe tener en cuenta que la carga de fichero permite a los usuarios el acceso adecuado para cargar cualquier tipo de contenido del fichero en el sistema. PTC no garantiza que los ficheros que se carguen sean seguros ni que la entrada proceda de un usuario de confianza.
|
En la información de este tema se proporcionan sugerencias sobre lo que no se debe hacer al configurar la seguridad en un modelo, así como las prácticas recomendadas para la configuración del modelo para que sea lo más seguro posible.
Gestión de la seguridad del servidor Edge
La gestión de la seguridad del servidor Edge es un aspecto importante de la protección de un modelo que empieza por la creación del modelo y continúa con implementaciones seguras. El servidor Edge es una barrera entre el entorno de modelado en ThingWorx (Composer) y los orígenes de datos externos. Hay muchas maneras de gestionar la seguridad de Edge en ThingWorx, incluida la utilización de la comunicación TLS/SSL para comunicarse entre el servidor Edge y la plataforma. La utilización de TLS/SSL produce lo siguiente:
◦ Las cosas remotas validan el servidor con certificados.
◦ El tráfico se cifra mediante TLS.
◦ Las claves de aplicación autentican las cosas remotas en la plataforma y el contexto del usuario asociado con la clave de aplicación restringe el acceso dentro de la plataforma.
Prácticas que se deben evitar
Aunque hay pasos que se pueden realizar para que el servidor Edge sea lo más seguro posible, algunas prácticas pueden reducir la seguridad global del sistema. Entre estas prácticas, se incluyen las siguientes:
• No se recomienda desactivar SSL. Incluso en móviles, algunas redes presentan fallos conocidos en la arquitectura de seguridad.
• Uso de certificados con hash vulnerables conocidos.
◦ No utilice MD5, SHA1, etc. Utilice alguna recomendación de NIST.
◦ No utilice certificados autofirmados fuera de desarrollo.
• Uso de la misma clave de aplicación para varios dispositivos. Autenticación de conexiones mediante claves de aplicación. Si las claves de aplicación no son únicas entre los dispositivos, será difícil auditar conexiones de suplantación o malintencionadas a través de las conexiones.
• Utilizar claves de aplicación con permisos generales. Esta práctica puede conducir a la concesión de acceso a activos para los que no deberían tener acceso.
Prácticas que se deben utilizar
• Utilizar una entidad de certificación de confianza.
• Utilizar la autorización de certificado de cliente: Mutual TLS.
|
|
El integrador de sistemas es responsable de la implementación de esta tecnología. Consulte la publicación C SDK Users Guide para obtener los detalles de implementación.
|
• Utilizar claves de aplicación. Al configurar las claves de aplicación y los usuarios de ThingWorx, se deben conceder siempre los permisos mínimos. No es una práctica recomendada asignar un miembro del grupo de administradores a una clave de aplicación.
Configuración del modelo
Para proteger completamente la aplicación, es siempre una práctica recomendada utilizar los siguientes principios:
• Concesión de los permisos mínimos
• Defensa en profundidad
• Valores por defecto seguros
1. Configuración de organizaciones
El primer paso en la creación de un modelo seguro para dispositivos Edge es definir correctamente la visibilidad para entidades mediante una organización. Las organizaciones pueden proporcionar la configuración de la visibilidad en todo el sistema para los usuarios con acceso adecuado para la aplicación.
2. Configuración de grupos de usuarios
Configure grupos de usuarios para desarrollar controles de acceso basados en roles de usuario.
|
|
En ThingWorx se proporcionan varios grupos de usuarios predefinidos. Para obtener más información, consulte Grupos de usuarios.
|
3. Configuración de usuarios
Los usuarios proporcionan acceso granular a los datos. Después de configurar las organizaciones y los grupos de usuarios, se debe crear un usuario para cada entidad permitida de forma única en la plataforma. Desde el punto de vista del servidor Edge, significa la creación de un usuario para cada dispositivo Edge que se conectará a la plataforma.
4. Configuración de claves de aplicación
Las claves de aplicación se utilizan para obtener acceso seguro a la plataforma y están vinculadas a un contexto de usuario para determinar los permisos. Se debe crear una clave de aplicación para cada dispositivo Edge que se vaya a conectar. Debe haber una proporción de 1:1 para las claves de aplicación y los usuarios o dispositivos.
5. Configuración de cosas remotas: permisos de visibilidad, fase de diseño y tiempo de ejecución
Después de crear la cosa remota, el primer contexto de seguridad que se debe definir es la visibilidad. La visibilidad afecta a las organizaciones y las unidades organizativas.
A continuación, se deben definir los permisos de fase de diseño. Los permisos de fase de diseño solo deben concederse a los usuarios de confianza que modificarán el funcionamiento y el modelo dentro de la aplicación. Normalmente, esto significa que el usuario o el dispositivo no tendrá permiso de fase de diseño, porque el dispositivo no debe poder modificar su propio funcionamiento.
Por último, defina los permisos de tiempo de ejecución para el usuario que representa el dispositivo de modo que este pueda contribuir funcionalmente a la aplicación. Los permisos de tiempo de ejecución son importantes para la granularidad. Como mínimo, se deben configurar permisos de tiempo de ejecución para que el usuario solo pueda acceder a la cosa. Si fuese necesario, se puede definir más granularidad en las propiedades.
Sugerencias adicionales para la configuración del modelo
• Es una práctica recomendada quitar todos los permisos de fase de diseño en un entorno de producción para evitar posibles regresiones en aplicaciones empresariales críticas. Todo el diseño debe implementarse y validarse dentro de un sandbox y, a continuación, implementarse en un entorno de producción solo después de una validación correcta de la aplicación.
• Los usuarios, las claves de aplicación y las cosas remotas se pueden crear mediante programación, pero los servicios creados para implementar esta función se deben controlar estrechamente dentro del modelo de seguridad de la aplicación y deben cumplir las instrucciones, tal como se describe en la sección anterior.
• Si hay dos cosas Edge conectadas a través del mismo EMS o SDK, no es posible asignar una clave de aplicación a cada cosa Edge. Si el modelo de permisos para estos dispositivos debe ser independiente, se recomienda que dichos dispositivos se conecten a través de SDK separados para proporcionar contextos de seguridad independientes para cada extremo de conexión.
• Si hay aplicaciones que requieren varios orígenes de datos por cosas remotas o si varios usuarios acceden a diferentes orígenes de datos de la misma cosa desde un mashup, los permisos de tiempo de ejecución se pueden definir en propiedades y servicios individuales.
• Cuando se trabaja con alguna entidad de tipo de almacenamiento de datos (wikis, blogs, tablas de datos, flujos y flujos de valor), se recomienda proporcionar permisos de ejecución de servicio al servicio del subsistema de plataformaGetDefaultDataPersistenceProviderName. Un usuario debe tener visibilidad de al menos un proveedor de persistencia en el sistema para crear nuevas cosas de tipo de almacenamiento de datos.