Remote Services: Key Concepts Used¶

This section provides an introduction into the basic concepts used in Remote Services (RS). Understanding these lays a good foundation for taking the first steps using RS.

Ways of Network-to-Network Access¶

RS was designed in a way, that it supports parallel 1:many access from single Service Network into many Device Networks.

The same RS mechanisms can be used for parallel many:1 access from multiple Service Networks into single Device Network.

Based on the above access modes, it is also possible to leverage 1:1 access or many:many access amongst networks.

Remark: when using setups with multiple networks, please consider, that these networks may belong to different (legal) entities, which may require an appropriate setup of users and access rights.

Typical Customers Working with RS¶

RS provides generic network-2-network access suitable for a large set of use cases such as remote maintenance, digitalization or integration of IoT apps or data storage.

This section outlines typical customers and their interests using the domain of remote servicing & maintenance as an example.

In this domain there are typically two types of parties:

• Service Provider: quite often an OEM or specialized business partner delivering "remote servicing & maintenance",
• Machine Operator: quite often the owner of a production line with machines (devices) procured from one or several OEMs

Under the assumption, that machines are linked to a computational and potentially embedded device, it is possible to access the status or wear or logs or business logic of such machines via a network interface.

In the first business scenario the Service Provider subscribes to RS: here a Service Provider services multiple Machine Operators either sequentially or in parallel. A Remote Service Technician uses his/her apps to supervise / diagnose / commission or maintain machines over a versatile secure network-to-network access mechanism.

For the Service Line Owner or CEO that has the advantage of reducing the need for their technicians travelling to Machine Operator sites, whilst also being faster at handling incidents such as unexpected machine behavior. If such travel is still necessary, upfront remote diagnosis helps to optimize the onsite-visit, e.g. by catering for replacement components.

In the second business scenario Machine Operator subscribes to RS: here a Machine Operator receives services from multiple Service Providers, who are specialized in different kinds of machines on the factory floor. So it becomes possible to receive best-in-class services for heterogeneous production lines with machinery purchased from different OEMs.

The benefit for the responsible Production Line Owner and the supporting CIO / CDO as well as the local maintenance experts on the factory floor are evident: the service providers deliver services specific to certain types of machinery such as faster incident resolution, update of software modules relevant for IT security, etc. They might even receive upgrades of a machine's capabilities through such dedicated remote access channels.

Blueprint for RS-Enabled Network-to-Network Access¶

This section outlines the key elements of a network setup involving RS. Further information on the key functional elements of RS can be found in the section Remote Services in a Nutshell

RS uses a catalog of Protocol Applications, which is created and maintained by RS' administrative user roles as outlined further down below.

• Service-2-Device protocols use case: "client app in Service Network and corresponding server app in Device Network"
• Device-2-Service protocols use case: "client app in Device Network and corresponding server app in Service Network"
• Furthermore, some of these protocol setups are predefined in terms of used ports or TCP/UDP, whilst others can be customized accordingly.

The key functionality of routing a customer app's IP-based protocols from one network to another is built on tunnels, which encrypt these protocols. Such tunnels need endpoints at either end, which allow for spawning them. Tunnel Endpoints are provided for download from within RS:

• One endpoint will be installed on a PC-type access device in the Service Network.
• Complementary endpoints will be installed on a PC-type device in a primary network of a Device Network.

That is a necessary pre-condition for establishing an encrypted connection using Web Socket Secure (WSS) tunnels between these devices. Endpoints may also be used in a gateway mode, so that connections to devices / apps / data residing in secondary networks can be established. Please note, that the network interfaces of the underlying devices must permit doing so.

RS also supports the web versions of the popular pre-configured remote login protocols of Remote Desktop Protocol (RDP), Virtual Network Client (VNC) and Secure Shell (SSH) so that both Windows® and Linux® devices can be reached. Please note, that the web versions of these protocols involve a www-browser running in the Service Network and that these have functional limitations over the also provided native versions of these protocols.

Each device can be assigned with one or more individual protocols, which paves the way for implementing a versatile set of use cases according to a customer's business needs.

Summarized, the provided software endpoints can be deployed on PC-type devices including selected Industrial Edge Devices (please refer to Appendix for Experts). Devices on secondary Device Networks do not require installation of an endpoint. Thus, devices in secondary networks can also be embedded devices, PLCs or SCADA systems, if they can be reached by a remote app via an IP-based protocol.

Fine-Grained Access Control for Many-to-Many Connectivity¶

So far we did outline how the encrypted tunnels, which route custom or pre-defined IP-based protocols, are being established. Now we introduce the important security mechanisms used in top, which ensure, that only authorized users may connect to authorized devices using the appropriate protocols - this concept is also known as Fine-Grained Access Control (FGAC) and a mandatory precondition for Zero Trust-driven setups as defined by NIST standard NIST.SP.800-207.

RS use a Device Tree for structured access to devices registered to it. As also depicted in Sample Setup Used in Documentation this tree has multiple layers, which could for instance by continents, countries, cities and campuses as indicated in the middle section of above picture.

• Root organizational or tenant level, e.g. "Europe"
• Sub-organizational or regional level, e.g. "Germany, etc." and "Munich, etc."
• Site level denoting a Device Network, e.g. "Brewery, etc."
• Devices will be registered to sites, e.g. "Pump, Motor, etc."

As outlined in RS in a Nutshell RS is hosted on Siemens cloud. So once RS is available in a specific tenant, already registered users can be assigned with additional RS-specific user roles, which allow for a task-specific separation of access rights and responsibilities as shown in the left section of above picture:

• Tenant Administrator: This RS role is authorized to administrate (change, read, update, delete) RS objects on organizational or tenant level. This responsibility includes onboarding of devices, definition of device-specific application protocols, definition of filters for device-types, assignment of RS roles to users and more. An administrator is assigned to one tenant and may administrate only that tenant’s objects and grants.
• Regional Tenant Administrator: This RS role is basically a scoped tenant administrator, who is only responsible for regional sub-organizations.
• Site Owner: This RS role is dedicated to managing a "Device Network" and the devices it contains. This includes installation of downloadable RS endpoints on devices. It has the authority to cut all connections to all a site's devices anytime at once.
• Remote User: This RS role is meant for users, who use preconfigured connections for performing everyday remote access tasks, such as remote maintenance of connecting apps or data across network boundaries. These users' access is limited to devices, for which they were granted access by an administrative RS role.

On top of that there is a Product Type filter shown on the right section of above picture. When Devices are onboarded to RS they may be tagged with administrator-defined Product Types. That allows giving Remote Users access only to specific classes or types of devices. For instance, it is also possible to define families such as Product Type "PC" and below that you may have particular types such as "PC with Windows" or "PC with Linux". Where necessary, it is also possible to assign grants for individual devices.

The following table summarizes the permissions and grants associated with the RS-specific user roles:

Please note, that the use of Tunnels in combination with Fine-Grained Access Control is an innovative approach, which lays the foundation for use cases not supported by classic perimiter-driven or network-driven security approaches such as VPNs. For further details please approach a Sales representative.

User Interface for Easy Self-Administration¶

After subscription to Remote Services you will see two RS-related icons in your tenant's launchpad:

• Remote Services V1 allows for anytime function calls and covers all RS functionality for administration, but also for everyday use, if a user was granted them via the respective RS user roles
• Remote Services V2 adds additional guidance via role-specific workflows including nested menus with a bread-crumb-style navigation across their call hierarchy. So this is meant for everyday use by people with the RS role Remote User

Menus have different appearances depending on their purpose and functionality. Below picture gives a first impression related to Remote Services V2:

• Icons to the very left allow for switching between different menu scopes such as configuration tasks or supervision of consumed contractual resources.
• The upper left bar shows the nested menu structure in a bread crumb. style
  
• Users who bear multiple RS-specific roles may switch them in the upper right bar.
• The left-hand tree structure shows the different organizations, regional sub-organizations, sites and devices registered to them.
• The key part is a workflow-specific edit and status area such as checking, which protocols were assigned to a particular device.