Patent Application
20250168166
The global economy has presented opportunities for organizations to work together regardless of physical and geo-political borders. Developments in network technologies, such as virtual private networks and remote desktop virtualization, have reduced the barriers for collaborative development. However, conventional remote access technologies often leave organizations vulnerable to security breaches and other risks. Without proper security measures, remote connections can provide a gateway for cybercriminals to gain unauthorized access to devices, modify and steal sensitive data. The vulnerabilities stem from weak user authentication policies, unsecured networks, lack of visibility into remote user activity and lack of physical security controls.
Attempts to solve this problem have fallen short. Traditional policies merely encourage users to not share their credentials or use weak passwords. Often virtual private networks are employed and advanced antivirus tools are installed. But these solutions still permit a direct connection to devices with little or no oversight. With a single connection, an intruder may obtain complete access to a network, applications and the files residing thereon.
For example, Original Equipment Manufacturers (OEMs) and fabrication plants (FABs) often need to communicate in a secure manner. In some scenarios, OEM engineers will need to remotely access equipment at the FAB plant to provide a FAB side engineer with the technical specifications for a particular piece of equipment produced by the OEM. And since the OEM side and FAB side are on different enterprise networks, it is difficult to establish a connection between the two without creating a vulnerability. More specifically, there is a need for OEM engineers to connect to equipment on the FAB side securely and reliably.
Effective remote access can also support an organization's sustainability efforts. For example, the remote access technologies described herein can reduce the amount of time individuals spend traveling, reducing the use of fossil fuels and greenhouse gas emissions. Furthermore, innovative technologies which permit this type of collaborative effort can reduce the demand on power grids by reducing the amount of office space needed in larger markets and thereby reducing the amount of electricity needed to power the lighting and HVAC systems to those office spaces.
The Connectivity platform provides secure, scalable, reliable, and transparent connectivity between Original Equipment Manufacturer (OEM) locations and OEM customer production plants (FABs). It facilitates the transport of data to and from Equipment located in a FAB and provides access for service engineers, for example, to remotely operate the Equipment. Preferably, this access is limited to authorized individuals and for authorized activities. The platform supports multi-tenancy, providing the service to multiple OEMs and multiple FABs while protecting FAB and OEM data privacy and intellectual property rights. The Connectivity platform may be managed by a service provider which may be independent from the OEMs and FABs that use it. Although the various embodiments may be discussed herein relative to OEMs and FABs, it is understood that the inventions described herein are applicable generally and are therefore not limited.
A few of the exemplary services include: Remote Take Over (RTO), Remote Command Execution (RCE), File Transfer, Security and Audit. In one embodiment, Remote Take Over allows the OEM engineer to take over the front-end of a machine located in a FAB. The RTO may be implemented using remote management tools such as Virtual Network Computing (VNC) and Remote Desktop Protocol (RDP). Remote Command Execution allows the OEM engineer to execute operating system commands at the machine located in the FAB. Preferably, the OEM is not connected directly to the FAB. That is, all exchanges between the OEM and the FAB pass through an intermediate service, e.g., a secure access service, which implements the zero-trust policy discussed herein. The Remote Command Execution commands may be restricted to a defined set of commands including a restricted set of command attributes and options. File Transfer allows the OEM engineer to transport files from and to the FAB. Preferably, files transported from the FAB may include log files and anonymized data files. Files transported to the FAB may include machine configuration data and software packages, updates and patches. The Equipment may include a plurality of applications, application files, etc. In this regard, the system may further restrict access to certain applications and to certain application data files, even when access to the given application has been granted. For example, the OEM user may be given access to control a data analytics application on the remote machine, but not certain files based on file type, or some other metadata associated with the file, including analytics data file types. In this regard, a remote IT person, for example, can RTO a device for application maintenance, but that person would not be able to access the application files that may contain confidential and/or highly sensitive information. Security and audit include processing activities which are logged and cannot be altered by the executing engineer. In one embodiment, data may leave the FAB only if properly authorized by a FAB engineer. Access to the Connectivity platform may be granted based on the federated Identity provider (IdP) of the OEM and FAB. Access of a given user or user group to certain equipment is controlled via Defined Permission Sets (DPS).
Additional aspects of the present invention will be apparent in view of the description which follows.
The present invention(s) is/are described in the following examples, which are set forth to aid in the understanding of the invention and should not be construed to limit in any way the scope of the invention as defined in the claims which follow thereafter.
The Connectivity platform 110 may include three main components: 1) a central user portal 205 that manages access requests from authorized users, 2) a core platform component which contains the central functions and integration capabilities of the service, and 3) one or more Edges at OEM locations and/or FAB locations for accessing OEM Equipment.
The central user portal 205 acts as the single “one-stop” entry point for requesting remote access, executing remote commands, and defining file transfer schedules at the Edges. The portal holds workflows for approvals and functionalities for: Remote Take Over (RTO), Remote Command Execution (RCE), file browsing, file transfer, web proxy, Defined Permission Sets (DPS) management, and/or user administration (such as add/remove). In one embodiment, the central user portal provides the workflows to manage the users of the Connectivity platform, which are not identified via the federated IdP. The central user portal may further provide the workflows to manage access permissions, their grouping into permission groups and the assignment of permission groups to Defined Permission Sets (DPS). Through the central user portal, authorized users can also submit a request for assistance when experiencing problems when requesting access to, or accessing, OEM equipment. In one embodiment, the central user portal also enables approval flow for items that either need OEM or FAB Approval, like file transfer schedules, Permissions, and/or other items.
The core platform is the main orchestration layer managing RTO, RCE, file transfer, web proxy and security and audit. This core may be located in a public cloud, and it enforces the zero-trust principle for services consumed through the platform, as discussed herein. In conjunction with the Connectivity core, an API may provide a generic REST API to interact with the Connectivity platform to authenticate, validate users, customers, equipment, and log requests for access.
In one embodiment, the FAB Edge is the environment deployed near a FAB, where near may be understood in terms of proximal network connectivity. The FAB Edge supports the zero-trust interface to the OEM engineer and connects to the OEM equipment in the FAB. In one embodiment, the OEM Edge is the environment deployed within the OEM environment to accommodate file transfers to/from the OEM self-managed file landing zone (or cloud destination). The Connectivity platform 110 may utilize an existing internet connection of the OEM and the FAB. Optionally, a network underlay service, such as an SD-WAN, provides a dedicated network connection between the OEM and the FAB, orchestrated by the Connectivity Core.
The overall system utilizes repeatable integration controls between vendor products, utilizing constructed coding and interfaces that provide a comprehensive policy using the zero-trust principle, allowing the Platform to co-exist and federate with an OEM and FAB. Pseudo access may be provided to the target systems, which provide role-based access controls (RBAC), alongside fine-grained privileges that the target systems may not possess. The combination of system features is adaptable to any industrial use where target systems with or without RBAC and fine-grained control require an integrated zero-trust mechanism. That is, the presumption is that users do not have access to the FAB and must request access each time access to the Equipment is desired. As noted above, access to equipment may be limited to authorized users.
In one embodiment, OEM service engineers will log in with their credentials (account/password) and authenticate themselves to their OEM IdP. At the onset, the OEM engineer will not have access to RTO/RCE, etc., and Equipment. The use of any particular piece of OEM equipment by a FAB may be confidential. As such, the information provided to the OEM engineer may be limited and/or anonymized. Thereafter, the OEM engineers make their requests for remote access, remote command execution or file transfer via the central user portal. This triggers approval flows towards OEMs and OEM Customers/FABs, either granting or denying access. After granting access, the option to access the equipment will be made available and the core platform provides a web-based browser link to the OEM service engineer, through which the OEM service engineer can access the equipment. The link may have an expiration, such as 30 minutes, for example. Consequently, an OEM service engineer can use the remote access functionality anywhere where public internet connectivity is available.
In one embodiment, the Connectivity platform is a multi-tenant platform designed to protect FAB and OEM data privacy and intellectual property rights. The core platform components may be advantageously designed to support multi-tenancy, i.e., core components serve multiple OEMs and FABs, whilst providing data segregation, so that a specific OEM service engineer can only view or update the subset of data that it is entitled by its organization to access. FAB Edge components also support multi-tenancy. In one embodiment, a FAB can use a single Edge instance to support all access functions provided by the service from multiple OEMs. One or more functions may be hosted on the same virtual or physical hardware. OEMs may be restricted to the specific equipment that they are authorized to access by the FAB.
FAB edge configuration may be configured in a variety of ways. At least one configuration is a physical FAB edge and the other is a cloud based virtual FAB edge. By default, the cloud FAB edge is the default way to connect to machines within a FAB. The physical FAB Edge may be utilized, if data stored in the FAB edge must reside in a FAB, so a cloud version is not feasible. In one embodiment, the physical FAB Edge is deployed into the network of the FAB, but isolated from the FAB network in a Connectivity platform De-Militarized Zone (DMZ) (e.g., via a set of inspection based firewall systems). Connection to the internet can either be enabled through an existing FAB internet facing DMZ and FAB ISP or through the optional network underlay connectivity provided by the Connectivity platform. The SD-WAN connectivity may be used for platform traffic.
As noted above, the default FAB connection is via a Cloud FAB Edge and an iVPN endpoint in the FAB from where the OEM equipment can be reached. This does not require any Connectivity platform specific hardware to be deployed and is the fastest way to connect a FAB to the Connectivity platform. The iVPN Endpoint and the routing to the OEM equipment within the FAB network may be provided by the FAB. In one embodiment, the Cloud Fab Edge consists of a set of virtual infrastructure and containers embedded between Firewalls and located in a public cloud environment. If a network underlay service is utilized, the FABs connected to that Edge, the network underlay appliance is deployed.
In one embodiment, the firewalls serve as an iVPN endpoint for connections to FABs. As such, the FAB utilizes a device that enables the FAB iVPN endpoint. In one embodiment, an optional endpoint can be deployed upon request if required. The Cloud Edge contains the software to authenticate connection requests and provides the interface and service inter-connections for: RTO, RCE, file transfer staging area for content inspection, web proxy to access web applications on the equipment in the FAB. In one embodiment, the Cloud Edge is multi-tenant, meaning that it can be used by multiple OEMs to connect to their managed equipment in the attached FABs.
OEM configuration may be accomplished in a variety of ways. In one embodiment, the OEM customer simply connects to the Connectivity platform via the Connectivity central user portal. In this regard, the OEM customer may connect through the OEM DMZ and Internet Service Provider (ISP) to the public internet and then to the Connectivity core, where the central user portal can be reached. For file transfer, the transfer scheduler and component of the Connectivity platform may be deployed locally to store files transferred by Connectivity platform from/to the OEM file store. They can either be sent through the OEM DMZ and ISP or through the optionally available network underlay service provided by Connectivity platform. In one embodiment, transfer of files can occur via Remote Access via the File-Browse & Download feature. This is at the OEMs discretion and governed by the Defined Permission Sets (DPS) es. The data security of a file transferred and stored in a location outside the Connectivity platform may be the responsibility of the OEM.
OEM configuration may also include a remote office site. The OEM Engineer remote office could be a location outside the OEM core location, such as an engineer's remote location as long as the engineer is authenticated against the OEM IdP. The file transfer still happens via the standard OEM Connectivity and the files are stored in the OEM file store after transfer, but the files are made available via an OEM provided replication mechanism to the admin site.
As can be seen in
In one embodiment, the OEM side includes an OEM enterprise network, file storage managed by the OEM, one OEM managed firewall interposed between the OEM enterprise network and a Connectivity network/DMZ. The Connectivity network may be in communication with the Connectivity platform scheduling virtual machines and a redundant firewall sitting on a network underlay. Two redundant ISPs may be in communication over the Internet to place the OEM in connection with the FAB side and vice versa. Like the OEM side, the FAB side may include a redundant firewall sitting on a network underlay which connects to the FAB Connectivity network. On the Connectivity network, edge appliances may be utilized to send unencrypted traffic through a single redundant FAB managed firewall leading to the FAB internal network and to the FAB equipment or tool.
In one embodiment, the cloud-based central user portal provides a workflow managed system for administering access and requesting Connectivity platform services such as file transfer, remote connectivity for OEM service engineers to equipment (e.g., file browse, download, etc.), remote command execution, a Cloud API for the use by programmatic interfaces and applications at the OEM, scheduling function for planned data transfers, reporting on usage. The Connectivity core may implement privacy policies in a variety of ways. In one embodiment, the Connectivity core uses identity federation towards OEM and OEM Customers, (i.e., OEM explicit user identities are not stored within the Connectivity platform). Additionally, access and transfer permissions are defined by OEMs and OEM customer security officers. This permits OEM Customers to remain accountable for validating access or transfer.
Data security in the Connectivity platform may be established via secure connectivity for data to be transferred and files are directly transferred from FAB Edges to an OEM receiving server at an OEM landing zone; or vice versa, from the OEM landing zone to the FAB Edge. In one embodiment, data may be stored for an agreed period of time in-transit within the Edge for the purpose of FAB inspection and also anti-virus scanning. Secure connectivity may be accomplished encrypting traffic flows between FAB Edges and the core platform. In one embodiment, the connecting system may use IPSec VPNs over an Internet link as the default connectivity for FABs towards the Cloud Edge. In general, the Connectivity platform logs all activities executed. In one embodiment, the data retention of the logs may be customizable to a customer's security policies and country regulations. Furthermore, monitoring data (telemetry) may be obfuscated based upon OEM and FAB in-transit policies.
One of the core functions of the Connectivity platform is remote access. In one embodiment, an authorized user (e.g., OEM service engineer) makes a remote access request through the Connectivity central user portal. If the OEM service engineer chooses the equipment for which their account or their user group has pre-approved remote access permissions, the request will be automatically approved.
If the OEM service engineer's account or user group does not yet have a pre-approved remote access permission for equipment, the OEM service engineer can still make a request for remote access, however the request will first need to be approved. Based on predefined workflows, the central user portal will start the approval process, which will typically involve approvals from both OEM and FAB security officers. Once approval has been granted, the OEM service engineer receives a link (URL), wherein access to the Edge Portal will be made available and the connectivity between the OEM engineer device and the FAB Edge Portal may be enabled via the Zero-trust configuration. An OEM service engineer can use the remote access service anywhere where HTTPS public internet connectivity is available.
When the OEM engineer accesses the equipment certain remote access options may be offered. One remote service option is web proxy. This option allows the OEM service engineer to view and select links to web contents that are hosted on the equipment. In one embodiment, only the links that are explicitly authorized may be shown. Another remote service option is a commands option. The commands option allows the OEM service engineer to request the execution of specific secure shell commands on the equipment. In one embodiment, only the commands that are explicitly authorized may be executed.
Remote Take-Over (RTO) may also be offered. RTO may be active or passive. When RTO is passive, this option enables a view-only RTO connection to the equipment. When RTO is active, this option enables an RTO Connection to the equipment enabling command execution for authorized commands. Remote Take Over (RTO) allows the OEM engineer to take over the front-end (screen) of a machine located in a FAB. The RTO is realized using remote management tools such as Virtual Network Computing (VNC) and Remote Desktop Protocol (RDP).
An additional remote access option is file browsing. This option provides the OEM service engineer with the option to browse specific folders on the equipment and to upload or download files to or from the equipment. In one embodiment, only the folders and files that are explicitly authorized will be shown. An additional service provided by the Connectivity platform is file transfer. File Transfer allows the OEM engineer to transport files to and from the FAB. Files transported from the FAB may include log files and anonymized data files. Files transported to the FAB may include machine configuration data and software packages, updates, and patches.
In one embodiment, an authorized user makes a file transfer request through the central user portal. The request may specify scheduled or on-demand transfers. If a request is made for a file for which the authorized user or the user's user group does not have pre-approved permission, then the request will require approval. The request will also require approval if it concerns a repetitive schedule. Based on predefined workflows, the central user portal will start the approval process, which may involve approvals from both OEM and FAB security officers. After approval has been granted, the request will be handled by the file transfer scheduler capability of Connectivity platform. This will generate the triggers for the actual file transfer(s) as stipulated in the request's schedule. It will also be possible for the user to see the list of file transfers scheduled in the future.
In one embodiment, each file transfer trigger is sent to the FAB Edge instance for execution. The FAB Edge relies on the trigger coming from the central user portal and does not allow a user to interfere or interact with the trigger. Once the trigger is received by the FAB Edge instance, file transfer is handled automatically. For a ‘Get’ request, the files are downloaded from the equipment to the FAB Edge instance, where they can be inspected by the FAB security officer or FAB administrator. Following inspection, if the file is released, it will be sent via a secure connection to a file landing zone at the OEM. For a ‘Put’ request, the files are retrieved from the file landing zone at the OEM and sent to the FAB Edge instance, where they can be further uploaded automatically onto the appropriate OEM Equipment. The file transfer capability provides visibility of transfer progress and remaining time to complete the transfer. It also offers the option to restart a transfer if it has failed. The end-to-end file transfer capability is designed to transfer files in accordance with agreed security policies.
Upon authentication, the Connectivity platform may define permissions 710 or permission bundles may be aggregated to defined permissions sets. Based on those permissions, an equipment list may be populated 715. From there, the user may be presented with an opportunity to select equipment 720. If access to the equipment is pre-approved 725, access is granted 740 and a link is sent to the user for access to the equipment through the central user portal. If pre-approved access has not been provided, the flow will then turn to a dual approval process 735 where the OEM and/or FAB side security officers/chaperones will approve access to that particular user. Once access is granted through the dual approval process, a link is sent to the user and access is granted 740. While providing the link 750, both the user network endpoint as well as the edge portal are configured dynamically for a zero-trust connection 745 to be established between these two network endpoints. In one embodiment, the user may have access to one or more features or functions for that specific piece of equipment, which allow them to interact with the equipment. The permission to access certain functions is enforced at the edge portal 755. For example, the functions available to the user may include RTO, RCE, file transfer, web proxy and equipment chat. The functions are then executed by a remote execution management and only that engine connects to the equipment itself.
In one embodiment, the OEM user portal acts as a galvanic separation that displays the interface of the machine that the user wants to control (view only). The chaperone device preferably sees the same screen that the OEM user sees. That is, a video stream of the interface at the remote equipment is duplicated by the middleware and communicated to both the OEM and chaperone users. Preferably, the video stream is relayed by the middleware only. That is, the video stream is not stored by the middleware.
The chaperone may then get a notice to promote the OEM user from view only to remote access. Once granted by the chaperone, the OEM user takes over the remote equipment, operating it as if the OEM user is physically on the machine being controlled. That is, the OEM user enters input at his/her device, which is sent to and translated by the middle software, and finally relayed to the remote equipment for the remote equipment to respond according to the input. Because the OEM user is not directly connected to the equipment, the middleware/chaperone may terminate and/or demote the session to a view only state. Importantly, because there is no direct connection, the OEM user is unable to run script or commands on the remote equipment, for example, without that script/command being seen by the middleware. Indeed, the middleware being situated as it is, is able to monitor every bit/byte in and out of the FAB equipment, allowing the fine-grained privileges and control discussed herein. Preferably, all decisions are logged for auditing in a mutable way.
Accordingly, the intermediary/chaperone has the ability to monitor actions by the OEM user with respect to the FAB equipment and respond accordingly in real time. The intermediary may include a machine learning model, for example, trained to monitor OEM actions and respond accordingly, including stopping the RTO session in whole or in part. The model may further be trained to recommend or take remedial action. For example, the model may monitor actions for potentially harmful changes to system files. In this instance, the system may prevent the changes from taking effect and/or roll back the changes, in addition to demoting access for the OEM. As discussed above, a chaperone may be employed, in which instance the chaperone is able to stop, pause, or demote the OEM user.
The following is a description of a general network architecture followed by a description of a software defined wide area network. Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term “server” as used throughout this application refers generally to a computer, other device, program, or combination thereof that processes and responds to the requests of remote users across a communications network. Servers serve their information to requesting “clients.” The term “client” as used herein refers generally to a computer, program, other device, user and/or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers across a communications network. A computer, other device, program, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a “node.” Networks are generally thought to facilitate the transfer of information from source points to destinations. A node specifically tasked with furthering the passage of information from a source to a destination is commonly called a “router.” There are many forms of networks such as Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc. For example, the Internet is generally accepted as being an interconnection of a multitude of networks whereby remote clients and servers may access and interoperate with one another.
Any node may include a processor in communication with memory. Generally, any mechanization allowing a processor to affect the storage and/or retrieval of information is regarded as memory. Any number of memory embodiments may be employed in lieu of or in concert with one another. It is to be understood that a bus controller and/or a computer systemization may employ various forms of memory. For example, a computer system may be configured wherein the operation of on-chip CPU memory (e.g., registers), RAM, ROM. In a typical configuration, memory will include ROM, RAM, and a storage device. A storage device may be any conventional computer system storage. Storage devices may include: an array of devices (e.g., Redundant Array of Independent Disks (RAID)); a drum; a (fixed and/or removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Blu Ray, CD ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.); RAM drives; non-transient memory, solid state memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable storage mediums; and/or other devices of the like.
The Connectivity platform relies on network connectivity between the OEM and the FAB. There are three illustrative ways connectivity may be established. First, connectivity may be established through the internet via the OEM Internet Service Provider (ISP) and the FAB ISP. Second, connectivity may be established through the OEM ISP and FAB ISP with a zero-trust layer on top. Third, connectivity may be established through an SD-WAN layer.
With respect to the zero-trust connectivity layer, for remote access, the OEM engineer issues a request over the public Internet to the central user portal, which triggers an approval workflow. Once the request has been approved, and the OEM engineer is provided with a link to access the FAB Edge, the traffic does not flow through the public Internet anymore, but through a network overlay for enhanced security referred to as the zero-trust overlay Network (ZTON). As opposed to the network traffic between the Connectivity orchestration layer and the Edges, the remote access scenario can originate from anywhere. This could be convenient for example if an OEM engineer is on travel. In one embodiment, it is possible to white-list source IP addresses corresponding to predefined ranges, e.g., corresponding to the OEM corporate network if desired. The ZTON may be accessed through so-called Public Service Edge Nodes (PSEN).
The network underlay is a virtual network that uses software-defined networking to distribute traffic across a wide area network. A network underlay may be utilized to connect branch offices to data centers and cloud-based applications. Network underlays are more flexible and cost-effective than traditional routing. They can use multiple connection types, including MPLS, LTE, and broadband internet. Network underlays can also improve network redundancy, bandwidth, and performance. Network underlays are different from VPNs because network underlays have multiple paths to choose from when routing traffic. VPNs only use one path. Network underlays are also different from firewalls. Firewalls enforce rules to determine the security of incoming and outgoing network traffic. Network underlays direct traffic through the best available route.
The functionality provided by the network underlay in the Connectivity platform may include Next Gen Firewall: The network underlay provides Next Gen firewall Capabilities on top of the network data transport layer. Network traffic into and out from the FAB and OEM is scanned for malicious content at the network and application layer. The data itself (the intellectual property) is not read nor stored. Network Security: network underlay creates secure IPsec tunnels over the underlay network. These tunnels guarantee secure point to point network connections between FAB, OEM and the Connectivity platform. Routing: The network underlay layer provides the routing capability to route network traffic towards the different destinations, such as OEM, FAB and the Connectivity platform.
In case multiple underlay networks are available the configuration provides the option to define redundant routes. A specific underlay network can be defined as the primary route for the network traffic (e.g., an internet connection), a secondary route can be defined over a different Underlay network (e.g., a 5G mobile network). The network underlay will automatically switch to the secondary network in case of unavailability of the primary network. Thus, providing a higher availability level of network connections.
The network underlay layer can provide QoS to the network. Specific network traffic flows can be prioritized over other, less important network flows. The QoS profiles are configured on the outset of an OEM on-boarding taking into account the KPIs relevant for the “T-Shirt” sizes identified. Their ongoing management is subject to provider change control mechanisms and capacity management routines described in the operational process of the Provider. Multi-OEM based configurations are constructed on the outset of a new OEM, based upon agreed KPIs and are bound to source and destination network schemas such that traffic bandwidth is harmonized between OEMs. This may drive additional capacity should a situation arise in OEM on-boarding that the new requirements exceed the already committed capacity granted over an existing QoS policy.
Flexibility and automation: The above features may be provided in a completely automated manner and are orchestrated via the central SD-WAN management. This automation ensures a more robust and stable network. Automation creates a high degree of flexibility and scalability in the network.
The network underlay connectivity layer is described as follows. When the Central User Portal instructs the Connectivity core orchestration layer, e.g., to initiate an approval workflow, the communication flows through a reliable and secure Network Overlay. When the Connectivity core orchestration layer subsequently instructs the Edge to execute further parts of the workflow, that network underlay network will be used too. It will also be used when the Edge needs to transfer data, logs for example, back to the Core Platform. In one embodiment, the connections are terminated at the core platform and at the edges in dedicated network underlay appliances.
While the foregoing invention has been described in some detail for purposes of clarity and understanding, it will be appreciated by one skilled in the art, from a reading of the disclosure, that various changes in form and detail can be made without departing from the true scope of the invention.
The application claims priority to U.S. Provisional Application No. 63/601,476, entitled SYSTEM AND METHOD FOR A CONNECTIVITY PLATFORM AND REMOTE MANAGEMENT, filed on Nov. 21, 2023, all of the contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63601476 | Nov 2023 | US |
