Trusted local orchestration of workspaces

Abstract

Systems and methods for providing trusted local orchestration of workspaces are described. In some embodiments, an information handling system (IHS) can include: a processor; and a system memory coupled to the processor, the system memory having program instructions stored thereon that, when executed, cause the IHS to: receive, from a workspace orchestration service, orchestration code; use a trusted controller coupled to the processor to record a log, the log including: the orchestration code, and an indication of a sequence of operations performed by a local management agent during instantiation of a workspace; provide, to the workspace orchestration service, a copy of the log; and in response to the workspace orchestration service successfully: (i) authenticating the orchestration code, and (ii) verifying the sequence of operations, establish a connection between the workspace and the workspace orchestration service.

Description

Technical Field

[0001] This disclosure generally relates to information processing systems (IHS), and more specifically, to systems and methods for providing trusted local orchestration of workspaces. Background Technology

[0002] As the value and uses of information continue to increase, individuals and businesses are seeking more ways to process and store it. One option is an Information Processing System (IHS). An IHS typically processes, compiles, stores, and / or transmits information or data for business, personal, or other purposes. Because the technology and information processing needs and requirements can vary between different applications, an IHS can also vary regarding: what information is processed, how it is processed, how much information is processed, stored, or transmitted, and how quickly and efficiently it can be processed, stored, or transmitted. Variations in IHS allow it to be general-purpose or configured for specific users or purposes (such as financial transaction processing, flight booking, enterprise data storage, or global communications). Furthermore, an IHS can include a variety of hardware and software components that can be configured to process, store, and communicate information, and can include one or more computer systems, data storage systems, and networking systems.

[0003] IHS provides users with the ability to access, create, and manipulate data, and typically implements various security protocols to protect this data. Historically, IHS has been designed to implement security paradigms that isolate the network from potential security threats, much like a castle is designed and built to protect those within its walls. For example, in the case of an IHS network, the security system implements a strategy that isolates the entire network from threats. In effect, a set of castle walls is built around the entire network. When working within the walls of such a system, users can be provided with secure and efficient data use.

[0004] However, the security paradigm of isolating protected data within the walls of a castle is increasingly hampered by the practical problems of modern computing. Today, users expect to access protected data using numerous different IHSs (Information Hierarchical Systems) while located in different physical locations. To leverage the security of the systems providing data access, current protocols supporting remote access have sought to extend the system's defenses to remote IHSs, essentially extending the castle walls to temporarily include all or part of the remote IHSs.

[0005] Another complexity of modern computing lies in the fact that users expect to be able to access some or all of their protected data using their own personal IHS, even if these users are provided with enterprise-issued IHS to access said data. For administrators of such systems, this increases the difficulty of protecting all possible means of accessing protected data. The need for a constantly growing list of software applications to support access to protected data, whether on personal or enterprise-issued IHS, significantly adds to this complexity. Furthermore, the need to support access to protected data from various physical locations and via various networks, including untrusted networks, further complicates the management of such systems. Faced with these problems, systems used to provide access to protected data are often difficult to manage, and ultimately, the data is not adequately protected, hindering its efficient use.

[0006] One known technique for protecting access to protected data via IHS is to use virtual machines or containers to isolate data in a separate or virtualized environment running on the IHS. Traditional types of virtualization environments provide varying degrees of isolation from the IHS hardware and operating system (OS). However, similar to the castle-wall defense of security paradigms that seek to isolate protected data within a security perimeter, traditional virtualization environments are not well-suited for modern computing. Specifically, these virtualization techniques establish an isolated computing environment on the IHS that allows users to access only data and applications approved for that user.

[0007] In some cases, conventional virtualization technologies can determine the data, applications, and protections to be provided on the IHS based solely on the user's identity, thus tending to implement all security protocols necessary for secure access to all approved data and applications. However, as the inventors have recognized, this not only results in complex virtualization work that consumes a significant portion of the IHS's memory and processing power, but also fails to consider what the user actually intends to do when operating the IHS.

[0008] As the inventors further recognize, modern computing should provide users with the ability to access protected data virtually anywhere via various IHSs. However, conventional virtualization fails to account for the specific context of IHS usage during a particular session, let alone the changes in that context. Furthermore, conventional virtualization technologies tend to support many functions that are not actually used. The overhead required to provide such unnecessary functionality places an excessive burden on IHS operations and reduces productivity and user experience. Summary of the Invention

[0009] Systems and methods for providing trusted local orchestration for a workspace are described. In one illustrative, non-limiting embodiment, an information processing system (IHS) may include: a processor; and a system memory coupled to the processor, the system memory having program instructions stored thereon that, upon execution, cause the IHS to: receive orchestration code from a workspace orchestration service; log using a trusted controller coupled to the processor, the log including: the orchestration code, and instructions for a sequence of operations performed by a local management agent during the instantiation of the workspace; provide a copy of the log to the workspace orchestration service; and, in response to the workspace orchestration service successfully performing: (i) authentication of the orchestration code, and (ii) verification of the sequence of operations.

[0010] When executed, the program instructions enable IHS to instantiate a workspace based on a workspace definition received from the workspace orchestration service. A workspace definition may include at least one of the following: threat monitoring level, threat detection level, threat analysis level, threat response level, storage confidentiality level, network confidentiality level, storage confidentiality level, display confidentiality level, user authentication level, information technology (IT) management level, regulatory compliance level, local storage control level, central processing unit (CPU) access level, graphics card access level, application usage level, or application installation level.

[0011] The trusted controller may include a Trusted Platform Module (TPM) chip configured to store one or more cryptographic keys that can be used for hardware authentication. Logs may be encrypted and stored in secure memory separate from system memory. Workspace instantiation may be performed without any communication between the local management agent and the workspace orchestration service.

[0012] Before logging, the program instructions, upon execution, may cause the IHS to: determine that the connection between the local management agent and the workspace orchestration service has limited bandwidth; and log in response to the determination. Alternatively, before logging, the program instructions, upon execution, may cause the IHS to: determine that the connection between the local management agent and the workspace orchestration service is intermittent; and log in response to the determination. Alternatively, before logging, the program instructions, upon execution, may cause the IHS to: determine that the local management agent is behind a firewall relative to the workspace orchestration service; and log in response to the determination.

[0013] The sequence of operations may include at least one of the following: configuring basic input / output system (BIOS) settings, installing applications, or executing security monitoring services.

[0014] In another illustrative, non-limiting embodiment, a memory storage device may have program instructions stored thereon that, when executed by the IHS of the workspace orchestration service, cause the IHS to: transmit orchestration code to a local management agent; receive a copy of a log recorded by the local management agent in an extended TPM, the log and the extended TPM measurements including: orchestration code, and indications of a sequence of operations performed by the local management agent during workspace instantiation; and establish a connection between the workspace and the workspace orchestration service in response to successful completion of: (i) authentication of the orchestration code, and (ii) verification of the sequence of operations.

[0015] In yet another illustrative, non-limiting embodiment, a method may include: receiving a workspace definition from a workspace orchestration service; receiving orchestration code from the workspace orchestration service in response to determining that the connection to the workspace orchestration service has limited bandwidth or is unreliable; instantiating a workspace based on the workspace definition; logging a log, the log including: orchestration code, and indications of a sequence of operations performed during instantiation; providing a copy of the log to the workspace orchestration service; and establishing a connection between the workspace and the workspace orchestration service in response to the workspace orchestration service successfully performing: (i) authentication of the orchestration code, and (ii) verification of the sequence of operations. Attached Figure Description

[0016] The invention is illustrated by way of example and is not limited to the accompanying drawings, in which similar reference numerals denote similar elements. The elements in the drawings are shown for simplicity and clarity and are not necessarily drawn to scale.

[0017] Figure 1 This is an illustration depicting examples of IHS components configured to modernize workspace and hardware lifecycle management within an enterprise productivity ecosystem, according to various implementation schemes.

[0018] Figure 2 This is an illustration depicting examples of methods for modernizing workspace and hardware lifecycle management within an enterprise productivity ecosystem, based on various implementation schemes.

[0019] Figure 3A and Figure 3B This is an illustration depicting examples of systems configured to modernize workspace and hardware lifecycle management within an enterprise's productivity ecosystem, based on various implementation schemes.

[0020] Figure 4 This is an illustration of an example of a trusted local orchestration method for providing a workspace, based on various implementation schemes. Detailed Implementation

[0021] For the purposes of this disclosure, an IHS may include any tool or set of tools operable to calculate, estimate, determine, classify, process, transmit, receive, retrieve, generate, switch, store, display, transmit, represent, detect, record, reproduce, dispose of, or utilize any form of information, intelligence, or data for commercial, scientific, control, or other purposes. For example, an IHS may be a personal computer (e.g., a desktop or laptop computer), a tablet computer, a mobile device (e.g., a personal digital assistant (PDA) or smartphone), a server (e.g., a blade server or rack server), a network storage device, or any other suitable device, and may vary in size, shape, performance, functionality, and price. Examples of IHSs are described in more detail below. Figure 1 Various internal components of an IHS configured to implement some of the described embodiments are shown. It should be understood that while some of the embodiments described herein can be discussed in the context of a personal computing device, other embodiments may utilize various other types of IHSs.

[0022] Figure 1 This is an illustration depicting components of an exemplary IHS 100 configured to protect dynamic workspaces within an enterprise productivity ecosystem. In some implementations, the IHS 100 can be used to instantiate, manage, and / or terminate workspaces, such as providing users of the IHS 100 with access to enterprise data while isolating that data from the operating system (OS) and other applications executed by the IHS 100 in a secure environment. In some implementations, the construction of workspaces for specific purposes and used in specific contexts can be remotely orchestrated from the IHS 100 by a workspace orchestration service, such as regarding... Figure 1 As described herein. In some embodiments, the various parts of the workspace orchestration can be executed locally on the IHS 100. The IHS 100 may be configured with program instructions that, when executed, cause the IHS 100 to perform one or more of the various operations disclosed herein. In some embodiments, the IHS 100 may be an element of a larger enterprise system comprising any number of similarly configured IHSs that communicate with each other via a network.

[0023] like Figure 1As shown, IHS 100 includes one or more processors 101, such as a central processing unit (CPU), operable to execute code retrieved from system memory 105. Although IHS 100 is shown as having a single processor, other embodiments may include two or more processors, each of which may be configured identically or configured to provide specialized processing functions. Processor 101 may include any processor capable of executing program instructions, such as an Intel Pentium family processor or any general-purpose or embedded processor implementing any of a variety of instruction set architectures (ISAs), such as x86, or ISA, or any other suitable ISA. Figure 1 In one embodiment, processor 101 includes an integrated memory controller 118 that can be implemented directly within the circuitry of processor 101, or memory controller 118 can be a separate integrated circuit located on the same die as processor 101. Memory controller 118 can be configured to manage the transfer of data to and from system memory 105 of IHS 100 via high-speed memory interface 104.

[0024] System memory 105, coupled to processor 101 via memory bus 104, provides high-speed memory for processor 101, which can be used by processor 101 to execute computer program instructions. Therefore, system memory 105 may include memory components suitable for supporting high-speed memory operations by processor 101, such as static RAM (SRAM), dynamic RAM (DRAM), NAND flash memory, etc. In some embodiments, system memory 105 may combine persistent non-volatile memory and volatile memory.

[0025] In some embodiments, system memory 105 includes a secure storage device 120, which may be a portion of the system memory designated for storing information such as access policies, component signatures, encryption keys, and other cryptographic information used in a secure workspace hosted on IHS 100. In such an embodiment, a signature may be calculated based on the contents of secure storage device 120 and stored as a reference signature. The integrity of the data stored in secure storage device 120 can then be verified by recalculating this signature of the contents of secure storage device and comparing the recalculated signature with the reference signature.

[0026] The IHS 100 utilizes a chipset 103, which may include one or more integrated circuits coupled to a processor 101. Figure 1In one embodiment, processor 101 is depicted as a component of chipset 103. In other embodiments, all or portions of chipset 103 may be implemented directly within the integrated circuits of processor 101. Chipset 103 provides processor 101 with access to various resources accessible via bus 102. In IHS 100, bus 102 is shown as a single element. However, other implementations may utilize any number of buses to provide the illustrated path served by bus 102.

[0027] As shown in the figure, various resources can be coupled to the processor 101 of the IHS 100 via chipset 103. For example, chipset 103 can be coupled to network interface 109, such as provided by a network interface controller (NIC) coupled to the IHS 100 and allowing the IHS 100 to communicate via a network (such as the Internet or a LAN). Network interface device 109 can provide wired and / or wireless network connectivity to the IHS 100 via various networking technologies, such as wireless cellular or mobile networks (CDMA, TDMA, LTE, etc.), Wi-Fi, and Bluetooth. In some embodiments, network interface 109 can support connections between trusted IHS components (such as trusted controller 115) and remote orchestration services. In such embodiments, the connection between the remote orchestration service and the trusted components supported by network interface 109 can be considered an out-of-band (OOB) connection isolated from the IHS's OS.

[0028] Chipset 103 may also provide access to one or more display devices 108 via graphics processor 107. In some embodiments, graphics processor 107 may be included within one or more video cards, graphics cards, or embedded controllers mounted as components of IHS 100. Graphics processor 107 may generate display information and provide the generated information to one or more display devices 108 coupled to IHS 100, wherein display devices 108 may include integrated display devices and / or external display devices coupled to IHS (such as via I / O port 116). In some embodiments, graphics processor 107 may be integrated within processor 101. One or more display devices 108 coupled to IHS 100 may utilize LCD, LED, OLED, or other thin-film display technologies. Each display device 108 may be capable of touch input, such as via a touch controller, which may be an embedded component of display device 108, graphics processor 107, or a separate component of IHS 100 accessed via bus 102.

[0029] In some implementations, chipset 103 may utilize one or more I / O controllers to access hardware components such as user input devices 111 and sensors 112. For example, I / O controller 110 may provide access to user input devices 111, such as keyboards, mice, touchpads, touchscreens, and / or other peripheral input devices. User input devices 111 may interface with I / O controller 110 via wired or wireless connections. Sensors 112 accessed via I / O controller 110 may provide access to data describing the environmental and operating conditions of IHS 100 (e.g., accelerometers, gyroscopes, hinge sensors, rotation sensors, Hall effect sensors, temperature sensors, voltage sensors, current sensors, IR sensors, photoelectric sensors, proximity sensors, distance sensors, magnetic sensors, microphones, ultrasonic sensors, etc.).

[0030] In some embodiments, chipset 103 may include a sensor hub capable of determining the relative orientation and movement of IHS 100 using information collected by sensor 112. For example, the sensor hub may utilize inertial motion sensors (which may include accelerometers, gyroscopes, and magnetometers) and be able to determine the current orientation and movement of IHS 100 (e.g., IHS 100 is stationary on a relatively flat surface, IHS 100 is moving irregularly and may be in transit, IHS 100's hinge orientation is vertical). In some embodiments, the sensor hub may also include the ability to determine the position and movement of IHS 100 based on network signal triangulation and network information provided by the OS or network interface 109. In some implementations, the sensor hub may support additional sensors, such as optical sensors, infrared sensors, and sonar sensors, which may support xR (virtual, augmented, and / or mixed reality) sessions hosted by the IHS 100 and may be used by the sensor hub to provide indications of the presence of a user in the vicinity of the IHS 100, such as whether the user is present, absent, and / or facing the integrated display 108.

[0031] When an end user is present before IHS 100, the sensor hub can also determine the distance of the end user from IHS, wherein this determination can be continuous, periodically spaced, or on request. Processor 101 can use the detected or calculated distance to classify the user as being in the near field (user's location < threshold distance A), mid-field (threshold distance A < user's location < threshold distance B, where B > A), or far field (user's location > threshold distance C, where C > B). As described in more detail below, failure to detect an IHS 100-certified user near IHS 100 may lead to a change in the IHS 100's security profile, thereby triggering a reassessment of the security risks of the workspace operating on IHS 100. A similar reassessment can be triggered based on the detection of additional individuals near IHS 100.

[0032] In embodiments where the IHS 100 can support various physical configurations (such as convertible laptops, N-in-1 devices, etc.), the sensor hub can utilize one or more pattern sensors 112 that collect readings that can be used to determine the current orientation of the IHS 100 in its physical configuration. In some embodiments, this orientation determination can be additionally performed using motion and orientation information provided by the sensors 112. For example, in laptop and convertible laptop embodiments, the processor 101 or trusted controller 115 can utilize the cover position sensor 112 to determine the relative angle between the two panels of the laptop to determine the mode in which the IHS 100 is physically configured. In such embodiments, the cover position sensor can measure the rotation angle of the hinge connecting the base panel and the cover panel of the IHS 100. In some embodiments, the processor 101 or trusted controller 115 can provide the collected cover position information, such as the hinge angle, to the sensor hub for determining the orientation of the IHS 100 in its configuration. In some embodiments, the sensor hub can directly interface with the cover position sensor when determining the hinge angle information.

[0033] The sensor hub can determine the orientation of the IHS 100 based at least in part on the rotational angle of its hinge from the closed position. A first hinge angle range from the closed position can indicate the laptop computer orientation, a second hinge angle range can indicate the landscape orientation, and a third angle range can indicate the tablet computer orientation. The sensor hub can also utilize orientation and movement information collected from the inertial motion sensor 112 to further determine the orientation in which the IHS 100 is physically configured. For example, if the sensor hub determines that the IHS 100 is configured with a hinge angle typical of a laptop computer, but the IHS 100 is oriented to its side, the IHS can be determined to be in book mode. If the IHS 100 is determined to be tilted such that the hinge is oriented between horizontal and vertical, the user's face is detected as facing the integrated display, and the IHS 100 is undergoing slight movement, the sensor hub can determine that the IHS 100 is being used in a book orientation. The sensor hub can determine that the IHS 100 is being used in a lateral orientation by determining that the IHS 100 is opened to a 180-degree hinge angle and is located on a flat surface. Similarly, the sensor hub can determine that the IHS 100 is in a tent configuration by detecting that the hinge angle is within a defined range (e.g., between 300 and 345 degrees) and that the IHS 100 is horizontally aligned and above the two display panels of the IHS 100.

[0034] Other components of the IHS 100 may include one or more I / O ports 116 for communicating with peripheral external devices and various input and output devices. For example, I / O ports 116 may include an HDMI (High-Definition Multimedia Interface) port and a USB (Universal Serial Bus) port for connecting external display devices to the IHS 100, through which various external devices can be coupled to the IHS 100. In some embodiments, external devices coupled to the IHS 100 via I / O ports 116 may include storage devices that support the transfer of data to and from the IHS 100's system memory 105 and / or storage devices 119. As described in more detail below, coupling of storage devices via I / O ports 116 may result in changes to the IHS 100's security profile, thereby triggering a reassessment of the security risks of the workspace operating on the IHS 100.

[0035] Chipset 103 also provides processor 101 with access to one or more storage devices 119. In various embodiments, storage device 119 may be integrated with IHS 100 or external to IHS 100. In some embodiments, storage device 119 may be accessed via a storage controller, which may be an integrated component of the storage device. Storage device 119 can be implemented using any memory technology that allows IHS 100 to store and retrieve data. For example, storage device 119 may be a magnetic hard disk drive or a solid-state drive. In some embodiments, storage device 119 may be a storage device system, such as a cloud drive accessible via network interface 109.

[0036] As shown in the figure, the IHS 100 also includes a BIOS (Basic Input / Output System) 117, which can be stored in non-volatile memory accessible via bus 102 from chipset 103. When the IHS 100 is powered on or restarted, processor 101 can utilize BIOS 117 instructions to initialize and test the hardware components coupled to the IHS 100. BIOS 117 instructions can also load an OS for use by the IHS 100. BIOS 117 provides an abstraction layer that allows the OS to interface with the hardware components of the IHS 100. The Unified Extensible Firmware Interface (UEFI) is designed as a successor to the BIOS. Therefore, many modern IHSs utilize UEFI in addition to the BIOS, or use UEFI instead of the BIOS. As used herein, the BIOS is also intended to include UEFI.

[0037] In the illustrated implementation, BIOS 117 includes a predefined memory or memory region, which may be referred to as NVM (Non-Volatile Memory) mailbox 106. In such an implementation, mailbox 106 can provide a secure storage location for storing workspace access policies, signatures, keys, or other data used for hosting and verifying workspaces on IHS 100. In some implementations, BIOS mailbox 106 can be used as a secure storage device utilized by a remote orchestration service to store access policies and keys for use in delivering and deploying secure containers on IHS 100. Secure storage devices 121 in BIOS mailbox 106 and system memory 105 can be used in this manner in place of or in combination with out-of-band functionality implemented by trusted controller 115.

[0038] In some implementations, the trusted controller 115 is coupled to the IHS 100. For example, the trusted controller 115 may be an embedded controller (EC) mounted as a component of the motherboard of the IHS 100. In various implementations, the trusted controller 115 may perform various operations supporting the transfer and deployment of workspaces to and from the IHS 100. In some implementations, the trusted controller 115 may interoperate with a remote orchestration service via an out-of-band communication path isolated from the OS running on the IHS 100. The network interface 109 may support such out-of-band communication between the trusted controller 115 and the remote orchestration service.

[0039] Trusted controller 115 can receive cryptographic information required for secure transmission and deployment of workspaces to IHS 100. In such an implementation, the cryptographic information can be stored in a secure storage device 121 maintained by trusted controller 115. Alternatively, trusted controller 115 can support the execution of a trusted operating environment that supports cryptographic operations for deploying workspaces on IHS 100. Alternatively, trusted controller 115 can support the deployment of workspaces within the OS of IHS 100 via an out-of-band communication channel isolated from the OS and allowing the workspace to communicate with the OS's trusted agent processes.

[0040] The Trusted Controller 115 may also support certain cryptographic processing for supporting the secure deployment and operation of a workspace on the IHS 100. In some embodiments, this cryptographic processing may be provided via operation of a secure operating environment hosted by the Trusted Controller 115, isolated from the software and other hardware components of the IHS 100. In some embodiments, the Trusted Controller 115 may rely on cryptographic processing provided by dedicated cryptographic hardware supported by the IHS, such as a TPM (Trusted Platform Module) microcontroller. In some embodiments, the secure storage device 121 of the Trusted Controller 115 may be used to store cryptographic information used in the authorization of the workspace.

[0041] In some implementations, the trusted controller 115 may be additionally configured to compute signatures that uniquely identify the various components of the IHS 100. In this case, the trusted controller 115 may compute hash values ​​based on the configuration of the hardware and / or software components coupled to the IHS 100. For example, the trusted controller 115 may compute hash values ​​based on all firmware and other code or settings stored in the onboard memory of hardware components (such as network interface 109). Such hash values ​​may be computed as part of a trusted process for manufacturing the IHS 100 and may be stored as a reference signature in secure storage device 121.

[0042] Trusted controller 115 can also be configured to recalculate hash values ​​for such components subsequently. The recalculated hash value for the component can then be compared with a reference hash value signature to determine if any modifications have been made to the component, indicating that the component has been compromised. In this way, trusted controller 115 can be used to verify the integrity of hardware and software components installed on IHS 100. In some embodiments, remote orchestration service 206 can verify the integrity of trusted controller 115 in the same manner by calculating a signature of trusted controller 115 and comparing it with a reference signature calculated during the trusted manufacturing process of IHS 100. In various embodiments, one or more of these operations supported by trusted controller 115 can be implemented using BIOS 117.

[0043] The trusted controller 115 can also perform operations involving interface with a power adapter when managing power for the IHS 100. This operation can be used to determine the power state of the IHS 100, such as whether the IHS 100 is operating on battery power or plugged into AC power. The firmware instructions utilized by the trusted controller 115 can be used to operate a secure execution environment, which may include operations for providing various core functions of the IHS 100, such as power management of the IHS 100 and management of certain operating modes (e.g., turbine mode, maximum operating clock frequency of certain components, etc.).

[0044] When managing the operating modes of the IHS 100, the trusted controller 115 can perform various operations to detect certain changes in the physical configuration of the IHS 100 and manage modes corresponding to different physical configurations of the IHS 100. For example, in the case that the IHS 100 is a laptop computer or a convertible laptop computer, the trusted controller 115 can receive input from the cover position sensor 112, which can detect whether both sides of the laptop computer have been locked together in a closed position. In response to the cover position sensor 112 detecting that the cover of the IHS 100 is locked, the trusted controller 115 can initiate operations to close the IHS 100 or put the IHS 100 into a low-power mode.

[0045] The IHS 100 can support various power modes. In some implementations, the power modes of the IHS 100 can be implemented through the operation of the trusted controller 115 and / or the OS of the IHS 100. In various implementations, the IHS 100 can support various power reduction modes to reduce power consumption and / or save battery power when the IHS 100 is not in active use, and / or control the user-available performance level by increasing or decreasing the maximum operating clock frequency of the components of the IHS 100 (e.g., processor 101).

[0046] In some implementations, IHS 100 may not include Figure 1 All components shown. In other embodiments, besides Figure 1 The IHS 100 may include other components as shown in the diagram. Furthermore, in Figure 1 Some components shown as independent components may alternatively be integrated with other components. For example, in some embodiments, all or part of the operations performed by the illustrated components may alternatively be provided by components integrated as a system-on-chip into processor 101.

[0047] Figure 2 This is an illustration depicting an example of a method 200 for protecting dynamic workspaces within an enterprise productivity ecosystem. For illustration, method 200 is divided into three phases: workspace initialization phase 200A, workspace orchestration phase 200B, and workspace termination phase 200C. During initialization 200A, users 201 (e.g., enterprise users) operate within a physical environment 202 (e.g., any type of environment and its associated context, including physical location, geographic location, location within a specific facility or building, detected network, time of day, user proximity, individuals near IHS 100, etc.) such as references. Figure 1 The IHS 100 described (e.g., desktop computers, laptop computers, tablet computers, smartphones, etc.).

[0048] Method 200 begins with an action by user 201 at launch point 203, which may be, for example, a corporate launch point provided by user 201's employer, a launch point 203 provided by the manufacturer of IHS 100, or a launch point provided to user 201 as a service by a third party. Specifically, user 201 operates IHS 100 to access launch point 203, which may be provided, for example, as a web portal, a portal application running in the OS of IHS 100, a dedicated portal workspace operating on IHS 100, etc. In various embodiments, launch point 203 may include graphical user interface (GUI) elements representing different software applications, data sources, and / or other resources that the user may expect to perform and / or operate. In various embodiments, the launch point may provide graphical, text, and / or audio interfaces through which user 201 can request data or other resources. In this way, a starting point can be provided to the certified user 201, which provides visibility into one or more software applications and an aggregation of user data sources available across all their data storage areas (e.g., local storage devices, cloud storage devices, etc.).

[0049] As described in more detail below, the workspace used to provide user 201 with access to requested data or other resources can be operated using a local management agent 332, which operates on IHS 100 and is configured to interoperate with workspace orchestration service 206. In various embodiments, launch point 203 may be provided in the form of a portal (e.g., a web page, OS application, or dedicated workspace) that allows user 201 to request access to managed resources. In various embodiments, launch point 203 may be hosted by remote workspace orchestration service 206, local management agent 332 on IHS 100, or any suitable combination thereof. Examples of launch point 203 technology may include WORKSPACE ONE INTELLIGENT HUB from WMWARE and Dell HYBRID CLIENT from Dell Technologies.

[0050] When user 201 selects to launch an application or access a data source managed by workspace orchestration service 206, initialization phase 200A begins. In response to an access request from user 201 (e.g., the user "clicks" the icon at launch point 203), IHS 100's local management agent 332 collects initial security and productivity context information at 204. For example, security context information may include attributes indicating the security risks associated with: the data and / or application being requested, the risk level presented by user 201, the hardware used by IHS 100, the logical environment of IHS 100 (where workspaces will be deployed to provide access to the requested data and / or application), and the current physical environment 202 of IHS 100.

[0051] Therefore, in this disclosure, the term "security context" generally refers to data or other information relating to the security posture in which a workspace will be deployed and utilized, wherein the security posture may be based on the user, IHS 100, data to be accessed via the workspace, and / or the environment 202. (See also: Regarding...) Figure 4 As described in more detail in Figure 5, security context can be quantified as a security risk score to support the assessment of the level or risk associated with providing user 201 with access to requested data and / or applications while using IHS 100 in a specific context. A "security risk score" generally refers to a numerical value that can be used to score, quantify, or measure the various security characteristics of the security context associated with the request. The risk score can be a total score associated with the overall security risk context, while a "risk metric" can be a risk measurement of a subcategory of a portion of the security context.

[0052] For example, security metrics that can be used to calculate a security risk score for a specific security context may include, but are not limited to: the classification of the requested data source and / or application, authentication factors used to identify user 201, the location of IHS 100, the role or other group classification associated with user 201, the authentication of the network used by IHS 100, the type of network used by IHS 100, the firewall configuration used by IHS 100, Indicators of Attack (IoA), Indicators of Conviction (IoC) regarding IHS 100 or the resource that user 201 is requesting, the patch level associated with the OS and other applications used on IHS 100, the availability of encryption, the types of encryption available, access to secure storage devices, IHS 100's use of provable hardware, and the degree of workspace isolation supported by IHS 100.

[0053] The term "productivity context" typically refers to user productivity in relation to a workspace, user, IHS, or environment. A "productivity score" typically refers to an index that can be used to rate, quantify, or measure the various productivity characteristics of a productivity context. Examples of productivity context information include, but are not limited to: IHS hardware, IHS software (including the OS), power status and maximum clock frequency of selected IHS components, peripheral devices permanently or temporarily coupled to the IHS, networks available to the IHS and the performance characteristics of those networks, software installers available on the IHS, etc.

[0054] Initial productivity and safety goals for the workspace can be calculated based on the context of user 201's actions combined with the productivity and safety context in which the workspace will operate. Productivity and safety goals can also be based on user 201's behavioral analysis, IHS 100 telemetry, and / or environmental information (e.g., collected via sensor 112). In some cases, at 205, a local management agent operating on IHS 100 can calculate initial safety and productivity goals based on the collected safety and productivity context. In other cases, a remote workspace orchestration service 206 can calculate safety and productivity goals.

[0055] As used herein, the term "security objective" typically refers to the attack surface presented by a workspace created and operated based on a workspace definition, while the term "productivity objective" typically refers to the productivity characteristics defined for a specific workspace. Examples of productivity objectives include, but are not limited to: the type of data or data source available to User 201, the minimum latency of the workspace, etc. Conversely, attributes that can be used to characterize a security objective may include, but are not limited to: the minimum security score of the workspace, the minimum trust score of IHS 100, authentication requirements for User 201 (e.g., how many authentication factors are required, the frequency of re-authentication), the minimum trust level in the network used by the workspace, the required isolation of the workspace from IHS 100, the ability to access a browser within the workspace, the ability to transfer data between workspaces, the ability to expand the workspace, etc.

[0056] Furthermore, the term "workspace definition" generally refers to a set of attributes describing how a workspace can be assembled, created, and deployed in a manner that satisfies both security objectives (i.e., the definition presents an attack surface with an acceptable level of risk) and productivity objectives (e.g., data access, access requirements, latency caps, etc.) based on the security context in which the workspace will be deployed and the productivity context (e.g., available device type and performance, network speed, etc.). Workspace definitions enable seamless migration of instantiated workspaces because they support the ability to assemble workspaces on any target OS or IHS configured to operate with the workspace orchestration service 206.

[0057] When describing the capabilities and constraints of a workspace, workspace definition 208 may specify one or more of the following: authentication requirements for user 201, the containment and / or isolation of the workspace (e.g., local applications, sandboxes, Docker containers, progressive web applications or "PWAs", virtual desktop infrastructure "VDI", etc.), the primary application that can be executed within the defined containment of the workspace to enable user 201 to utilize one or more data sources for production, additional applications that enhance productivity, security components that reduce the scope of security objectives presented by the productivity environment (e.g., DELL DATA GUARDIAN from Dell Technologies, antivirus software, etc.), the data sources to be accessed and the requirements for routing that data to and from the workspace containment (e.g., using a VPN, minimum encryption strength), the workspace's ability to independently attach other resources; and so on.

[0058] In some implementations, workspace definitions may be based at least in part on static policies or rules, for example, defined by the enterprise's information technology (IT) personnel. In some implementations, static rules can be combined and improved using machine learning (ML) and / or artificial intelligence (AI) algorithms that evaluate historical productivity and security data collected throughout the workspace's lifecycle. In this way, rules can be dynamically modified over time to generate improved workspace definitions. For example, if it is determined that a user dynamically adds a text editor each time they use Microsoft's Microsoft Visual Studio, the workspace orchestration service 206 can autonomously add that application to that user's default workspace definition.

[0059] Still referencing Figure 2 During orchestration 200B, initial security and productivity goals are addressed and / or reconciled for resources, device capabilities, and available cloud services to generate a workspace definition at 208. As described, the workspace definition can specify the capabilities and constraints of the workspace, such as: runtime security requirements for the workspace enclosure (e.g., isolation from the OS of IHS 100 or certain hardware of IHS 100), demonstrating the integrity of the workspace once operational using reference measurements, providing applications for operation within the workspace, aggregation of resources available via the workspace, access configurations (e.g., Virtual Private Network or "VPN"), etc.

[0060] The initial workspace definition can then be utilized by the automation engine 302 of the workspace orchestration service 206 to coordinate the assembly 209 and instantiation 210 of the workspace on an appropriate platform (e.g., in the cloud or on IHS 201) based on the security and productivity context in which the workspace will operate. In the case of a cloud-hosted workspace, the automation engine 302 can assemble and instantiate remote workspaces that can be accessed via a secure connection established through a web browser or other web-based components operating on IHS 100. In some implementations, the automation engine 302 can resolve configuration conflicts between the workspace definition and user input during workspace operation.

[0061] At 211, the instantiated workspace is operated by user 201, and at 212, new productivity and security context information related to the data's behavior or usage is generated. This operation of the workspace can lead to changes or new classifications of the data based on what user 201 has done, accessed, and / or created, thus resulting in a change in the workspace's security context. These changes in the security context can be used as additional input for the automation engine 302 to re-evaluate security and performance objectives at 207, provided that user behavior analysis, device telemetry, and / or the environment have changed to a quantifiable degree. Alternatively, new workspace contexts, security objectives, and / or productivity objectives can now be measured against initial objectives, and, if applicable, the results can lead the automation engine 302 to generate a new workspace definition at 208.

[0062] Specifically, if the instantiated workspace has parameters that fall outside the range of the target index, causing the difference between the additional or updated context information and the initial or previous context information to be scored below a threshold, then the automation engine 302 can process the assembly of modifications to the existing workspace and deploy such modifications at 210. Conversely, if the difference between the additional or updated context information and the initial or previous context information is scored above a threshold, then the automation engine 302 can generate a new workspace at 210. The data aggregation engine 336 can store session data metadata and context, and can restore session data when applicable.

[0063] Alternatively or concurrently, as part of termination phase 200C, method 200 may terminate or deactivate the initial or previous workspace at 214. In some cases, user actions may initiate the termination process (e.g., user 201 closes an application or browser accessing data) and / or termination may occur automatically as part of adjustments to the workspace definition (e.g., automation engine 302 instructs the isolation environment to terminate). Still as part of termination phase 200C, workspace resources at IHS 100 and / or workspace orchestration service 206 may be released.

[0064] Thus, in various implementations, method 200 ensures user productivity even when the workspace operates on an unmanaged IHS or cloud platform. Method 200 also provides dynamic or adaptive configurations and policies, allowing for the best possible user experience while maintaining an appropriate level of security. In some cases, the definition of the productivity environment and access requirements can be selected based on productivity and security dependencies and objectives, and the definition of workspace-related capabilities can be inherently adaptive. Specifically, workspace definition attributes can be dynamically selected based on historical productivity and security information, and based on the behavior of each individual user or group.

[0065] Figure 3A and Figure 3B Illustrations show examples of system components 300A and 300B (collectively, “System 300”) configured to modernize workspace and hardware lifecycle management within an enterprise productivity ecosystem. Specifically, component system 300A includes a workspace orchestration service 206, and it may include one or more remotely located and / or networked IHSs storing program instructions that, upon execution, cause one or more IHSs to perform various workspace orchestration operations described herein, including but not limited to: dynamically assessing security and productivity objectives based on updated context information received from IHS 100; calculating risk scores and other productivity and security metrics based on continuous context information collection; generating workspace definitions; and assembling one or more files or policies that instantiate workspaces according to workspace definitions at cloud services and / or IHS 300B.

[0066] Component 300B includes an IHS 100 on which program instructions can be stored, which, when executed, cause the IHS 100 to perform various local management operations described herein, including but not limited to: collecting productivity and security context information, calculating productivity scores and / or risk scores, instantiating, executing, and modifying workspaces based on files or policies (such as workspace definitions) received from workspace orchestration service 206.

[0067] Workspace Orchestration Service 300A and IHS 300B can be coupled to each other via any suitable network technology and / or protocol, which allows Workspace Orchestration Service 300A to be provided remotely relative to IHS 300B. (See reference...) Figure 1 The IHS, according to the implementation scheme, may include components such as a trusted controller, which may support certain out-of-band communications of the OS independent of the IHS 100. In some implementations, such a trusted controller may be configured to support the deployment and operation of the workspace on the 300A and report changes in context information to the workspace orchestration service 300A.

[0068] like Figure 3A As shown in component 300A, workspace orchestration service 206 may include multiple sub-components supporting the deployment, continuous evaluation, and adaptation of workspaces on IHS 300B. Implementations of workspace orchestration service 300A may include systems that can support web service 306, manufacturer integration 317, and analytics 323. Furthermore, web service 306 may include application service 301 and user interface (UI) and automation service 302.

[0069] Analysis service 323 can be configured to receive and process contextual information from IHS 300B during initial workspace configuration and ongoing support of the workspace, and provide this information, along with any generated analytics, to the context logic 303 of application service 301. Based on information collected during workspace deployment and ongoing support, support assistance intelligence engine (SAIE) 324 can be configured to generate and / or analyze technical support information (e.g., updates, bugs, support logs, etc.) for diagnosing and resolving workspace issues. Workspace insight and telemetry engine 325 can be configured to analyze and / or generate device-centric, historical, and behavior-based data generated by workspace operations (e.g., hardware measurements, feature usage, settings, etc.). Workspace intelligence 326 may include any suitable intelligence engine for processing and evaluating contextual data to identify patterns and trends in workspace operations and adaptations based on contextual changes.

[0070] As shown in the figure, the application service 306 system of workspace orchestration service 300A includes a UI and automation service 302 system, which may include context logic or engine 303, classification strategy 304, and condition control module or engine 305. Context logic or engine 303 can support the processing of contextual information during risk assessment (e.g., assessing a user's risk-related requests based on the context of user behavior, the user's IHS history, the user's IHS capabilities, and environmental conditions). For example, security context information collected by IHS 300B can be provided to workspace orchestration service 300A, where this information can be used by context logic 303 to calculate risk scores associated with requests using managed data sources and / or applications. Classification strategy 304 may include administrator- and machine learning-defined strategies describing risk classifications associated with different security contexts (e.g., risk classifications for specific data, location, environment, IHS, logical environment, or user actions) (e.g., using high-risk data requires using a workspace definition suitable for use with risk scores above a certain value). The condition control module or engine 305 may include intelligence to provide automated decision-making to appropriately align risks and context. In some cases, the condition control module or engine 305 may dynamically deploy solutions to address any detected misalignment of risk and context. For example, when a request for access to a highly confidential data source results in a significant increase in the risk score, the condition control engine may choose to implement workspace definition modifications that apply to security procedures suitable for higher risk scores.

[0071] Application service 301 may include a set of web services 306 invoked by UI and automation services 302 to support various aspects of workspace orchestration. Specifically, web services 306 may include application and workspace services 307 that can assemble and package applications for deployment in a workspace (e.g., a “.msix” file is packaged and deployed to a MICROSOFT HYPER-V container). In some implementations, workspace definitions can be used to specify whether access to the application will be provided to users in this manner. Web service 306 may also include a tenant subscription module 308 that performs dynamic configuration of the IHS and deployment of the described workspace orchestration services at the IHS’s point of sale (POS). License tracking module 309 can be used to maintain and track license information for software, services, and the IHS. Access control module 310 can provide top-level access control for controlling authorized user access to data and applications. Unified endpoint management (UEM) module 311 can be configured to support the orchestration of workspaces on various different IHSs that can be utilized by specific users.

[0072] Web service 306, which can be used to support workspaces, may also include resource provisioning service 312 for configuring IHS or workspaces with secrets / credentials required to access specific resources (e.g., credentials for VPNs, networks, data repositories, workspace encryption, workspace authentication, and workspace-to-device anchoring). In some cases, resource provisioning service 312 may include secrets provided as part of the trusted assembly process of IHS 300B, and in some cases, associated with a unique identifier 348 of IHS 300B. Web service 306 may also include an authorization / token module that provides identity functionality and may connect to various authentication sources, such as Active Directory. Endpoint registration module 314 may be configured to register IHS and / or workspaces with a management service that tracks the use of the described workspace orchestration. In some cases, directory service module 315 may be configured to provide Active Directory services (e.g., Azure Active Directory from Microsoft Corporation). Device configuration service 316 implements centralized configuration, monitoring, management, and optimization of workspaces that can be remotely operated from IHS in certain contexts and may present images of workspace outputs only to IHS users. Device configuration service 316 can also collaborate with resource provisioning service 312 to handle secret creation and IHS configuration, and in some cases, can have out-of-band capabilities and handle selected operations to the endpoint.

[0073] Still referencing Figure 3A The manufacturer integration component 317 communicates with the application service 301 and the client IHS 300B to provide features available during workspace evaluation and instantiation, where these features are based on information available to the manufacturer of the client IHS 300B. For example, the certification authority 318 may include an entity that issues digital certificates that can be used to verify the authenticity and integrity of the IHS 300B's hardware. The identity service module or engine 319 can be configured to manage the identity of users or owners and agent identifiers for use with the customer directory 322. The order rights module or engine 320 can be responsible for managing purchased rights and associated issued certificates signed by 318. The ownership repository 321 can manage user rights associated with the IHS and its ownership, and can support users in transferring ownership of the IHS and transferring rights associated with it. In certain circumstances, the ownership repository 321 can use such ownership transfer to unlock secrets associated with rights embedded in the IHS. Customer directory 322 can be configured to authenticate and authorize all users and IHSs on the network, such as assigning and enforcing security policies for all IHSs and installing or updating software (in some cases, customer directory 322 can work together and / or can be the same as directory service 315).

[0074] Now for reference Figure 3B In some implementations, the IHS 300B can be configured to operate a local management agent 332, which can be controlled by a trusted controller 341 (such as...). Figure 1 The trusted controller 115 operates within a secure execution environment 345. In other embodiments, the local management agent 332 may operate as a trusted and provable process of the OS of the IHS 300B. In some embodiments, the local management agent 332 may include a workspace engine suitable for instantiating and managing the operations of one or more workspaces 331A to 331N on the IHS 300B. As described above, the capabilities of a workspace can be modified based on changes in the productivity and security context in which the workspace operates. Therefore, workloads in each of the workspaces 331A to 331N may be hosted in a public cloud, a private cloud, a specific server, or locally hosted on the IHS 300B, depending on the context in which the workspace is operating. These allocations computed for each specific workspace 331A to 331N may be specified by a workspace definition used to build and operate each workspace. As described, workspace definitions can be created by workspace orchestration service 206 based on contextual information provided by IHS 300B, security objectives for each workspace 331A to 331N, and productivity objectives for each workspace 331A to 331N.

[0075] In some implementations, the local management agent 332 may be configured to host, launch, and / or execute a workspace hub 327 that provides a launch point 203 through which a user launches a workspace by selecting managed data and resources. In various implementations, the launch point 203 may be an agent, application, dedicated workspace, or web portal that provides an interface through which a user can select from a collection of data sources, applications, calendars, messages, or other managed information or resources available to the user of the IHS 300B via operations on the workspace as described herein. In various implementations, the launch point 203 may be provided in the form of a text, graphical, and / or audio user interface that allows the user of the IHS 300B to select available data and / or resources. In some implementations, the workspace hub 327 may utilize the local environment management module 328 to provide a workspace interface presented to the user on the IHS 300B, and do so consistently across workspaces 331A through 331N. Workspace hub 327 may also include local intelligent logic or engine 329 for supporting modeling of the use of IHS 300B to improve the characterization of actual risks associated with the risk context. User authentication and access control operations may be performed by local identification module 330, which may interface with trusted controller 341 when providing user authentication.

[0076] In some cases, each instantiated workspace 331A to 331N can be an environment that provides a user with access to requested data or applications, wherein the environment may be isolated to varying degrees from the hardware and software of the IHS 300B based on the security and productivity context in which each workspace 331A to 331N operates. In some cases, selecting a data source or resource available to a user via launch point 203 may result in the launch of a new workspace. For example, if a user launches a browser by selecting an icon displayed by launch point 203, a new workspace can be created and launched based on a workspace definition that has been selected to provide the user with access to the web browser in the security and productivity context in which the request has been made. In cases where a user double-clicks a confidential presentation file obtainable from a data source provided by launch point 203, an additional workspace can be instantiated using a presentation application that provides access to the requested presentation file, wherein this new workspace is created based on a workspace definition that provides appropriate security for access to the confidential presentation. In other cases, the user's selection of presentation files can make the presentation available through the existing workspace. In some cases, the existing workspace definition is used, while in others, a workspace definition that has been modified to support the requested access to confidential presentation files is used.

[0077] Although workspaces 331A to 331N supported by the IHS 330B can be isolated from and from each other to varying degrees by the hardware and / or software of the IHS 300B, IHS 330B users may expect to be able to operate multiple workspaces 331A to 331N in a manner that allows content to be transferred between different workspaces 331A to 331N. For example, a user can select a portion of the data displayed in workspace 331A and use the OS or other workspace functions to copy the data to workspace 331B.

[0078] In various embodiments, the local management agent 332 may operate wholly or partially on a security platform 345 hosted by a trusted controller 341, which operates independently of the IHS 300B's OS. In some embodiments, the local management agent 332 may operate wholly or partially as a trusted component of the IHS 300B's OS. To perform the various operations described herein, the local management agent 332 may include a command monitor 334 configured to provide tools to receive commands from a workspace orchestration service 300A, thereby enabling access to the IHS 300B. The local management agent 332 may also include a telemetry module 335 configured to transmit collected information to the workspace orchestration service 300A, including reporting changes that, in the context, can guarantee adjustments to workspaces 331A through 331N. A data aggregator 336 may track all data sources and other resources (e.g., applications, on-premises or cloud-based services) available to users via the workspace.

[0079] Local management agent 332 may utilize resource manager module 337, which is configured to manage access to data, network configuration (such as VPN and network access), identity information, access control, and resource provisioning services. Security module 338 may be configured to provide various security services. BIOS interface 339 may provide a secure BIOS interface for accessing and managing credentials in a secure object storage device. BIOS analysis module 340 may be configured to perform forensic services for BIOS telemetry and health assessment. Persistence module 346 may be configured to support the persistence of applications authorized at the POS or assigned by an administrator and tracked using the required licenses. Workspace authentication module 333 may provide a platform-centric service layer on top of the container engine provided by local management agent 332 and may be used to measure and authenticate workspaces 331A to 331N in any suitable manner defined or orchestrated by condition control 305.

[0080] As part of the security platform 345, the native management module 347 can be configured to enable an out-of-band management interface with the workspace orchestration service 206, wherein this OOB interface is independent of the IHS 300B's OS operation. In some implementations, the OOB management interface supported by the native management module 347 can be used by the workspace orchestration service's device configuration service 316 to access the IHS 300B's security platform service 345.

[0081] The digital device ID module 348 can provide a unique, spoofable, and cryptographically bound identifier. In embodiments supporting the secure platform 345, the secure embedded controller 341 can be a hardened hardware module that may include a root trust module 342 configured as a trusted data storage area, and in some cases, can be trusted within a cryptographic system for cryptographic processing. The device authentication service 343 can be configured to perform device assurance and trust services (e.g., secure BIOS and secure boot). A secure object store 344 can be provided, configured to lock and access keys, hashes, and / or other secrets in the EC and / or TPM.

[0082] In some cases, the IHS 100 may be provided by the manufacturer of the control manufacturer integration component 317, and the workspace authentication module 333 may operate in conjunction with the secure object storage area 344, the certified BIOS module 339, and / or the digital device identity module 348, etc., to further protect and / or control the productivity features available in any of the workspaces 331A to 331N based on the IHS-specific and / or manufacturer-specific hardware devices and settings.

[0083] To further illustrate how the systems and methods described in this paper operate to modernize workspace and hardware lifecycle management within an enterprise productivity ecosystem, three non-restrictive use cases or examples are discussed below.

[0084] Use case A

[0085] In use case A, a given user can use a company-owned and imaged laptop to request access to a protected data source within the corporate premises, such as information about... Figure 1 IHS 100 and Figure 3B Configure it as described in the IHS 300B client.

[0086] In response to the request, the local management agent 332, operating on the user's laptop, retrieves information describing the current context and calculates security and productivity goals based on the determined context. In this use case, the local management agent may already be installed by IT and may be running as a service in the background. Confidential data can be associated with the local management agent on the local machine based on file classification (e.g., file metadata / type / attributes / licenses, folder location, encrypted areas, etc.). Furthermore, the local management agent can continuously collect current context information and send it to an orchestration service for scoring the risk and productivity of the workspace (this can also be done upon user access requests or intent indications).

[0087] When a user selects confidential data (such as by selecting via the laptop's OS), the local management agent notifies the workspace orchestration service of the request and the workspace definition of the workspace through which the user can be provided with access to the confidential data.

[0088] In this example, the workspace orchestration service can use a weighted machine learning or artificial intelligence algorithm to score the overall security risk with a value of "2" based on the following contextual information or input, where each contextual information or input is also given as a risk metric based on the selected policy: Location: 1 (secure location); User Role: 1 (known high confidence in a fairly complex user classification—users who have never clicked on phishing emails in the past); Network Risk: 1 (low risk due to the detection of an on-premises wired connection); Device Risk: 1 (high level of control due to the company-owned / managed platform, known version, enabled security features, etc.); Regulatory: 1 (based on a combination of user, data, and location—e.g., no restrictions on the General Data Protection Regulation or "GDPR", the Health Insurance Portability and Accountability Act "HIPAA", the Payment Card Industry "PCI", technology export, etc.); and Data Type: 8 (requesting confidential data files).

[0089] The workspace orchestration service can also use weighted machine learning or artificial intelligence algorithms to calculate a productivity score with a value of "9" based on the following contextual information or input, where each contextual information or input is also given as a resource metric based on the selected strategy: Location: 10 (office); User role: 9 ("proficient" category based on advanced computing tasks, proficiency, and / or speed); Network speed / latency: 10 (fast, wired, gigabit Ethernet, or direct connection to the internal network); Device performance: 8 (fast, expensive CPU, memory, graphics card, but storage is only required - e.g., <10GB); and Data type: 10 (local confidential files are easy to read / write, with low latency and high performance on local storage devices).

[0090] Second, based on security scores and / or context information, the workspace orchestration service constructs workspace definition files with any suitable structure, the structure having workspace definition attributes in a machine-readable format (e.g., JSON name values, XML structured, etc.). In this example, a security objective can be considered to have a value of "1" based on a combination of attribute values ​​representing the load, need, or requirement for security control and containment features. These security control and containment features may include: Threat Monitoring: 1 (low requirement); Threat Detection: 1 (low requirement); Threat Analysis: 1 (low requirement); Threat Response: 1 (low requirement); Storage Confidentiality: 2 (low); Storage Integrity: 2 (low); Network Confidentiality: 1 (low); Network Integrity: 1 (low); Memory Confidentiality: 1 (low); Memory Integrity: 1 (low); Display Confidentiality: 1 (low); Display Integrity: 1 (low); User Authentication: 1 (low, basic password sufficient, not multi-factor authentication or "MFA", no session expiration); IT Administrator Scope: 1 (remote management by administrators but no heavy-duty remediation software required); and Regulatory Compliance: 1 (no GDPR, no HIPAA, no PCI, no technology export restrictions, etc.).

[0091] Based on productivity goals and / or contextual information, and based on the following combination of attribute values ​​representing productivity requirements, the productivity goals defined in the workspace can be considered to have a value of "9" (defining a high-quality, responsive user experience): Local storage: 7 (partial hard drive control, reserving some storage for IT load); CPU access: 10 (unrestricted); Local graphics card: 10 (unrestricted); and Application stack: 10 (applications can be used, applications that users need can be installed, and administrator privileges can be granted to them, etc.).

[0092] Third, after the workspace definition is complete, the workspace orchestration service and the local management agent can assemble the workspace and instantiate it for the user. For example, the local management agent can receive definition files (e.g., JSON, XML, etc.) from the orchestration service, and it can parse the files to implement security risk controls such as: Threat Monitoring: 1 (The local management agent does not install threat, detection, and response, or "TDR" software); Threat Detection: 1 (The local management agent does not install TDR software); Threat Analysis: 1 (Orchestration does not require collecting detailed telemetry data from the system, and the OS does not register it in the logs); Threat Response: 1 (The local management agent does not install a security threat response agent); Storage Confidentiality: 2 (The local management agent deploys a local file system encryption product, which the user can optionally enable for specific files via a right-click context menu); Storage Integrity: 2; Network Confidentiality: 1 (The local management agent verifies that the basic firewall configuration is correct—e.g., IT...) (GPO controlled); Network integrity: 1; Storage confidentiality: 1 (Local management agent verifies configuration—e.g., no SGX, TXT, or container / sandbox software deployed); Storage integrity: 1; Display confidentiality: 1 (Local management agent verifies graphics card drivers are installed, privacy screens and cameras are optionally managed by the user); Display integrity: 1; User authentication: 1 (Local management agent verifies basic GPO password rules are configured and users meet these rules—e.g., character count, no session expiration, etc.); IT administrator scope: 1 (Local management agent runs with system privileges and verifies that the IT administrator account is listed in the local administrator user group—e.g., according to the GPO); and Regulatory compliance: 1 (Local management agent does not install any compliance-enhancing software).

[0093] After the configuration is confirmed, the workspace orchestration service and local management agent can grant users access to the requested local confidential files, and users can begin working in the newly created workspace.

[0094] Use Case B

[0095] In use case B, users can use an open public network and IT-managed / owned PCs (such as those for information about...) in a coffee shop. Figure 1 IHS 100 and Figure 3B (The client is configured as described in the IHS 300B) to request access to confidential data files.

[0096] First, the local management agent (332), executed by the client IHS (300B), retrieves the requested context and calculates security and productivity scores based on the context. In this use case, the local management agent may already be installed by IT and may be running as a service in the background. Confidential data may be stored on a shared, IT-managed network resource deployed internally (e.g., back in the main corporate office), and the local management agent may be responsible for monitoring when a user requests that data path (e.g., when a user clicks a specific URL, IP, etc.). Furthermore, the local management agent may continuously collect all current context and send it to a workspace orchestration service to assist in scoring the process later (this could also be done when a user requests access or points to a diagram, rather than continuous collection).

[0097] When the user selects the desired confidential data file, the OS of the client IHS (300B) calls the local management agent associated with the path to the confidential data file and calls back the remote workspace orchestration service (206) to request a workspace definition.

[0098] In this example, the workspace orchestration service can use a weighted machine learning or artificial intelligence algorithm to score the overall security risk with a value of "4" based on the following contextual information or input, where each contextual information or input is also given as a risk metric based on the selected policy: Location: 5 (public, safe country); User role: 5 (new user, categorical data not yet available); Network risk: 5 (medium, public but common location, wireless connection detected); Device risk: 1 (high level of control, company-owned / managed platform, known version, enabled security features, etc.); and Regulatory: 1 (based on a combination of user, data, and location – for example, no restrictions on the General Data Protection Regulation or "GDPR", the Health Insurance Portability and Accountability Act "HIPAA", the Payment Card Industry "PCI", technology export, etc.).

[0099] Workspace orchestration services can also use weighted machine learning or artificial intelligence algorithms based on contextual information or inputs to calculate a productivity score with a value of "5", where each piece of contextual information or input is also given as a resource metric based on a selected strategy. For example, security contextual inputs could include: Location: 6 (remote location, but in a major U.S. city, in a public area, non-employees within the device's visual / auditory range); User Role: 5 (unknown confidence "empty" classification, using default onboarding assumptions); Network Speed / Latency: 4 (medium, wireless but AC on a shared network); and Device Performance: 8 (fast, expensive CPU, memory, graphics card, but storage only ~<10GB).

[0100] Second, based on security scores and / or context information, the workspace orchestration service constructs workspace definition files with any suitable structure, the structure having workspace definition attributes in a machine-readable format (e.g., JSON name values, XML structured, etc.). In this example, a security objective can be considered to have a value of "4" based on a combination of attribute values ​​representing the load, need, or requirement for security control and containment features, which are as follows: Threat Monitoring: 4 (Medium requirement); Threat Detection: 4 (Medium requirement); Threat Analysis: 4 (Medium requirement); Threat Response: 4 (Medium requirement); Storage Confidentiality: 4 (Medium); Storage Integrity: 9 (High); Network Confidentiality: 5 (Medium); Network Integrity: 2 (Low); Memory Confidentiality: 4 (Medium); Memory Integrity: 8 (High); Display Confidentiality: 7 (Medium / High – Concern about “shoulder snoops” reading data from nearby adjacent seats or tables in public places); Display Integrity: 2 (Low); User Authentication: 4 (Medium, using two-factor authentication with hardware tokens, session expiration during sleep, screen lock or logout); IT Administrator Scope: 3 (Administrators can remotely monitor, manage, and remediate if users seek help from them regarding IT issues); and Regulatory Compliance: 1 (No GDPR, no HIPAA, no PCI, no technology export restrictions, etc.).

[0101] Based on productivity goals and / or contextual information, and based on the following combination of attribute values ​​representing productivity requirements, the productivity goals defined in the workspace can be considered to have a value of "7" (defining a high-quality, responsive user experience): Local storage: 7 (partial hard drive control, reserving some storage for IT load); CPU access: 10 (unrestricted); Local graphics card: 10 (unrestricted); and Application stack: 7 (applications can be used, and some IT-approved applications that the user needs can be installed, but there are no administrator privileges because it cannot be trusted that the user will only install valid / secure productivity software, but pre-approved IT applications can be installed as needed).

[0102] Third, after the workspace definition is complete, the workspace orchestration service and the local management agent can assemble the workspace and instantiate it for the user. For example, the local management agent can receive definition files (e.g., JSON, XML, etc.) from the orchestration service, and it can parse the files to implement security risk controls, such as: Threat Monitoring: 5 (the local management agent installs or verifies the previous installation / configuration of the TDR software); Threat Detection: 5 (the local management agent installs or verifies the previous installation / configuration of the TDR software); Threat Analysis: 5 (the orchestration verifies that telemetry data is accessible, and registers it in the log if the OS has not yet registered it); Threat Response: 2 (the local management agent downloads but does not run the remote event response application—preparing for event detection); Storage Confidentiality: 5 (the local management agent deploys local container technologies with restricted "save" permissions, such as sandboxes, so that confidential files will not be allowed to be saved locally on the PC, but can be accessed as long as the session is active in storage); Storage Integrity: 5; Network Confidentiality: 5 (the local management agent strengthens firewall protection, disables all unnecessary ports, and...) Establish a VPN back to the company office to protect traffic to the local sandbox); Network Integrity: 5; Storage Confidentiality: 5 (The local management agent configures the sandbox container to isolate applications and data from other applications / threats that may infiltrate the host OS); Storage Integrity: 5; Display Confidentiality: 7 (The local management agent verifies that the graphics card driver is installed, enforces privacy screens, and uses the camera to detect specific bystander threats); Display Integrity: 7; User Authentication: 4 (The local management agent verifies that basic GPO password rules are configured and that users meet these rules—e.g., character count, no session expiration, etc.—but also adds the requirement to log in with a hardware token and re-establish the network); IT Administrator Scope: 4 (The local management agent runs with administrator and remote access permissions, verifying that the IT administrator account is listed in the local administrator user group—e.g., according to the GPO); and Regulatory Compliance: 4 (The local management agent installs state-specific rule enforcement or monitoring software).

[0103] After the configuration is confirmed, the workspace orchestration service and local management agent can grant users access to the requested local confidential files, and users can begin working in the newly created workspace.

[0104] Use Case C

[0105] In use case C, the user can have information such as about Figure 1 IHS 100 and Figure 3BThe client IHS 300B, configured as described, allows internet cafes using borrowed / rented PCs on open WiFi networks to request access to confidential data files in a web-hosted remote portal using a browser from Kazakhstan.

[0106] First, the remote workspace orchestration service (332) intercepts access requests and evaluates browser and user context, calculating security and productivity scores. In this use case, there is no local management agent; all that is known is the browser and any telemetry data returned or collected via an HTTP / S session. For the purposes of this example, it is assumed that confidential data may be stored on a shared IT-managed network resource deployed internally (e.g., back in the main corporate office), and the data files will remain there with only remote presentation / access rights. Web-based context may be collected via browser sessions or supplied by the user. Additionally, user context may be collected for the workspace orchestration service via alternative secondary channels (e.g., travel calendar information, recent user billing activity on corporate credit cards, telephone call logs, and / or location data).

[0107] When a user selects the desired confidential data file from a web browser, the backend web server infrastructure calls back the workspace orchestration service to request a workspace definition.

[0108] In this example, the workspace orchestration service can use a weighted machine learning or artificial intelligence algorithm to score the overall security risk with a value of "9" based on the following contextual information or input, where each contextual information or input is also scored as a risk metric based on a selected policy: Location: 9 (Kazakhstan); User Role: 1 (The user is expected to be there, based on past logins, the time appears to be correct, and he has a biometric watch communicator proving that he is alive, himself, and located at the location he says—so that IT can always trust him); Network Risk: 9 (High, public, and in a very hidden location); Device Risk: 9 (Zero Trust); and Regulatory Risk: 8 (based on a combination of user, data, and location).

[0109] The workspace orchestration service can also use weighted machine learning or artificial intelligence algorithms to calculate a productivity score of 5 based on the following contextual information or inputs, where each contextual information or input is also given as a resource metric based on the selected strategy: Location: 3 (no high-performance internet cafe equipment); User role: 9 (known high confidence and "skilled" classification - advanced computing tasks, skill level, and speed); Network speed / latency: 3 (low quality - wireless G from a distant location); and Equipment performance: 3 (must be able to browse the web tolerably, but the service should build simple web pages based on its perceived capabilities).

[0110] Second, based on security scores and / or contextual information, the workspace orchestration service constructs workspace definition files with any suitable structure, the structure having workspace definition attributes in a machine-readable format (e.g., JSON name-value pairs, structured XML, etc.). In this example, based on a combination of attribute values ​​representing load, requirements, or demands for security control and containment features, a security objective can be considered to have a value of "9," as follows: Threat Monitoring: 10 (High Demand, to be processed on the server side); Threat Detection: 10 (High Demand, to be processed on the server side); Threat Analysis: 10 (High Demand, to be processed on the server side); Threat Response: 10 (High Demand, to be processed on the server side); Storage Confidentiality: 10 (High Demand, to be processed on the server side); Storage Integrity: 8; Network Confidentiality: 10 (High Demand, to be processed on the server side); Network Integrity: 9; Storage Device confidentiality: 10 (High requirement, to be processed on the server side); Memory integrity: 9; Display confidentiality: 10 (High, "shoulder snoops" could read data files from nearby adjacent seats or tables in public places); Display integrity: 9; User authentication: 10 (High, using three-factor authentication with login, hardware token, and biometric identification of the satellite watch—session expires and refreshes every 30 seconds); IT administrator scope: 8 (Administrators can remotely monitor, manage, and repair if users seek help from them or if any unexpected situation occurs); and Regulatory compliance: 10 (All network traffic is securely monitored, as is the data presented).

[0111] Based on productivity goals and / or contextual information, and based on the following combination of attribute values ​​representing productivity requirements, the productivity goals defined in the workspace can be considered to have a value of "3" (defining a usable secure user experience primarily built for consumption rather than productivity): Local storage: 1 (caching only); CPU access: 3 (built for limited expectations); Local graphics card: 3 (built for limited expectations); and Application stack: 1 (web browser experience on a kiosk-mode device, limited data input capabilities, and limited read access to only the information that needs to be known via a kiosk rendered via VDI).

[0112] Third, after the workspace is defined, the workspace orchestration service and the remote cloud web portal (e.g., a user's login session via a browser) can assemble the workspace and instantiate it for the user in the browser. For example, a web portal can receive definition files (e.g., JSON, XML, etc.) from an orchestration service, and it can parse these files to implement security risk controls such as: Threat Monitoring: 9 (data center-based management agents install or verify previous installations / configurations of TDR software); Threat Detection: 9 (data center-based management agents install or verify previous installations / configurations of TDR software); Threat Analysis: 9 (orchestration verifies that telemetry data is accessible, and servers hosting web servers can register in logs if they are not already registered—and can also continuously monitor user behavior telemetry data from secondary channels to detect suspicious / abnormal activity); Threat Response: 10 (data center-based management agents set watchdog timers to automatically terminate sessions without requiring periodic checks from orchestration, user telemetry, and web browsers); Storage Confidentiality: 9 (data center-based management agents build progressive web applications that can be used to display data over a secure TLS link—data will be presented, but only the necessary portions of the visualization will be shown to the user, and no content will be saved); Storage Integrity: 10; Web Network confidentiality: 9 (By making every effort to route traffic to a secure location—nothing other than bitmap rendering is allowed over the enforceable network); Network integrity: 4; Storage confidentiality: 9 (Web viewer only—no data leaves the data center, no confidential input is obtained from the leased PC, keyboard input is not allowed, and all input can be captured from a randomized virtual keyboard using mouse click coordinates); Storage integrity: 8; Display confidentiality: 8 (By making every effort to ensure confidentiality—at least prompting the user—font size can be adjusted, but defaults to small font, blurred text, etc.); Display integrity: 2; User authentication: 9 (The local management agent confirms that basic password rules are configured and that the user meets these rules—e.g., character count, no session expiration, etc., but also adds requirements for logging in and re-establishing the network using hardware tokens and biometric satellite watches, requiring frequent reconfirmation from the user); IT administrator scope: 7 (Remote environment based on the data center); and Regulatory compliance: 8 (The local management agent does not exist, but the data center-based agent is not suitable for monitoring / blocking data).

[0113] After the configuration is confirmed, the workspace orchestration service and local management agent can give users access to the requested presentation data, and users can start working in the newly created workspace.

[0114] ***

[0115] The systems and methods described herein can be implemented to provide trusted local orchestration of workspaces, which is particularly useful in situations where, for example, the local management agent 332 and the workspace orchestration service 206 are effectively isolated during the execution of the workspace instantiation process of the local management agent 332.

[0116] For example, in some cases, the network connection between the local management agent 332 and the workspace orchestration service 206 during workspace instantiation may have limited or restricted bandwidth, or the connection may be intermittent (e.g., down or unstable). In other cases, the workspace orchestration service 206 may be protected behind a firewall or demilitarized zone that does not allow connections from endpoints that do not have a trusted workspace already in place. Furthermore, the local “administrator” agent is often assigned an account with high privileges that can be used to tamper with logs, thereby eroding the workspace orchestration service 206’s ability to trust the instantiation sequence performed by the local management agent 332. In these and various other situations, the workspace orchestration service 206 may not be able to monitor every local activity during workspace instantiation.

[0117] To address these issues, the systems and methods described herein can provide trusted local orchestration of the workspace, generally as follows: First, the workspace orchestration service 206 and / or the local management agent 332 determine that the connection between them has limited bandwidth, is intermittent, etc. In response, the workspace orchestration service 206 transmits a unique random number or code to the local management agent 332, which can act as a local management agent to perform complex sequences of instantiation operations based on a given workspace definition (e.g., configuration of Basic Input / Output System (BIOS) settings, application installation, or execution of security monitoring services, etc.). During the local instantiation process, communication between the local management agent 332 and the workspace orchestration service 206 may be limited or nonexistent, and the management agent 332 may log or digitize instantiation activities and operations (e.g., anonymized local personally identifiable information or “PII” context assessment, software ID or “SWID” tag logging, configuration, installation, etc.) and extend them to the TPM chip or trusted controller.

[0118] The TPM chip provides integrity protection for the activity sequence of the local management agent 332. After the workspace is instantiated and the connection between the workspace orchestration service 206 and the local management agent 332 is established, the workspace orchestration service 206 can then verify the completion of the sequence by comparing it with the new TPM quote verification record or log.

[0119] Figure 4This is an illustration of an example of a method 400 for providing trusted local orchestration of workspaces. In various implementations, method 400 may be performed by a local management agent 332 in collaboration with a workspace orchestration service 206. At 401, the workspace orchestration service 206 deploys the local management agent 332 on the IHS 100, and / or it transmits a unique instantiated random number or orchestration code to an existing local management agent 332. At 401, the workspace orchestration service 206 may also transmit workspace definitions to the local management agent 332.

[0120] At 402, the local management agent 332 determines that its connection to the workspace orchestration service 206 is blocked (e.g., by policy), lost, and / or intermittent. In response, at 403, the local management agent 332 instantiates the workspace locally. During the instantiation of the workspace, at 404, the local management agent 332 records a copy of the orchestration code and a record of the instantiation operation sequence and sends (or extends its measurements) to the TPM, which then stores the information in secure memory separate from the endpoint's system memory.

[0121] In some cases, the detection of network problems in box 402 can occur at some point in the instantiation process, and the local management agent 332 can start storing records of the instantiation operation in the TPM from that point as part of the local orchestration process.

[0122] At 405, the local management agent 332 re-establishes the connection to the workspace orchestration service 206 and requests the instantiated workspace service. In response, at 406, the workspace orchestration service 206 requests instantiation or orchestration of a measurement from the TPM and requests the measurement logs from the local management agent. At 407, the local management agent delivers the logs, and the TPM verifies the measurement.

[0123] At 408, the workspace orchestration service 206 verifies whether the sequence of operations in the log matches the expected or permitted operations (e.g., based on the workspace definition). The workspace orchestration service 206 also authenticates the orchestration code in the log against the original orchestration code. If both verification and authentication are successful, at 409, the workspace orchestration service 206 can provide connectivity and / or services to the workspace.

[0124] In various implementations, the TPM platform configuration register (PCR) (using TPM2_PCR_extend), non-volatile storage (using TPM2_NV_extend), or similar methods can be used to record the sequence of operations during workspace instantiation. In this way, the TPM may be able to provide new evidence that the sequence of operations was performed on a given workspace during the request, and / or that it has not been tampered with or replayed from a previous instantiation.

[0125] It should be understood that the various operations described herein can be implemented in software executed by processing circuitry, hardware, or a combination thereof. The order in which each operation of a given method is performed can be changed, and various operations can be added, reordered, combined, omitted, modified, etc. The invention described herein is intended to encompass all such modifications and variations, and therefore, the above description should be considered illustrative rather than restrictive.

[0126] As used herein, the terms “tangible” and “non-transitory” are intended to describe computer-readable storage media (or “memory”) that do not transmit electromagnetic signals; however, they are not intended to otherwise limit the types of physical computer-readable storage devices covered by the phrases “computer-readable medium” or “memory.” For example, the terms “non-transitory computer-readable medium” or “tangible memory” are intended to cover types of storage devices that do not necessarily permanently store information, including, for example, RAM. Program instructions and data stored in a non-transitory form on a tangible computer-accessible storage medium can then be transmitted via a transmission medium or signal, such as an electrical signal, electromagnetic signal, or digital signal, which can be transmitted via a communication medium such as a network and / or a wireless link.

[0127] Although the invention has been described herein with reference to specific embodiments, various modifications and alterations may be made without departing from the scope of the invention, as set forth in the appended claims. Therefore, the specification and drawings are to be considered illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the invention. Any benefits, advantages, or solutions to problems described herein with reference to specific embodiments are not intended to be construed as key, essential, or necessary features or elements of any or all claims.

[0128] Unless otherwise stated, terms such as “first” and “second” are used to arbitrarily distinguish the elements described by such terms. Therefore, these terms are not necessarily intended to indicate a temporal or other priority order of such elements. The term “coupled” or “operably coupled” is defined as a connection, but not necessarily a direct connection or a mechanical connection. Unless otherwise stated, the terms “a” and “an” are defined as one or more. The terms “comprise” (and any form of inclusion, such as “comprises” and “comprising”), “have” (and any form of having, such as “has” and “having”), “include” (and any form of inclusion, such as “includes” and “including”), and “contain” (and any form of containing, such as “contains” and “containing”) are open-ended connecting verbs. Therefore, a system, apparatus, or device that “comprises,” “has,” “includes,” or “contains” one or more elements possesses, but is not limited to, possessing only those elements. Similarly, a method or process that "includes," "has," "contains," or "comprises" one or more operations has, but is not limited to having only, those one or more operations.

Claims

1. An information processing system (IHS), the IHS comprising: processor, and System memory coupled to the processor, the system memory having program instructions stored thereon that, when executed, cause the IHS to: In response to determining that the connection to the workspace orchestration service has limited bandwidth or is unreliable, orchestration code is received from the workspace orchestration service; A trusted controller coupled to the processor is used to log information, the log including: the orchestration code, and indications of the sequence of operations performed by the local management agent during instantiation in the workspace; After the instantiation of the workspace, a copy of the log is provided to the workspace orchestration service, wherein communication between the local management agent and the workspace orchestration service is limited or nonexistent during the instantiation process of the workspace; and A connection is established between the workspace and the workspace orchestration service in response to the successful completion of the following: (i) authentication of the orchestration code, and (ii) verification of the operation sequence.

2. The IHS of claim 1, wherein the program instructions, when executed, further cause the IHS to instantiate the workspace based on a workspace definition received from the workspace orchestration service.

3. The IHS as described in claim 2, wherein the workspace definition includes at least one of the following: threat monitoring level, threat detection level, threat analysis level, threat response level, storage confidentiality level, network confidentiality level, memory confidentiality level, display confidentiality level, user authentication level, information technology (IT) management level, regulatory compliance level, local storage control level, central processing unit (CPU) access level, graphics card access level, application usage level, or application installation level.

4. The IHS of claim 1, wherein the trusted controller includes a Trusted Platform Module (TPM) chip configured to store one or more cryptographic keys that can be used for hardware authentication.

5. The IHS as described in claim 4, wherein the logs are encrypted and stored in a secure storage location separate from the system storage.

6. The IHS of claim 1, wherein the instantiation of the workspace is performed without any communication between the local management agent and the workspace orchestration service.

7. The IHS of claim 1, wherein, prior to logging the log, the program instructions, upon execution, further cause the IHS to: It is determined that the connection between the local management agent and the workspace orchestration service has limited bandwidth; and The log is recorded in response to the determination.

8. The IHS of claim 1, wherein, prior to logging the log, the program instructions, upon execution, further cause the IHS to: It was determined that the connection between the local management agent and the workspace orchestration service was intermittent; and The log is recorded in response to the determination.

9. The IHS of claim 1, wherein, prior to logging the log, the program instructions, upon execution, further cause the IHS to: It is determined that the local management agent is located behind a firewall relative to the workspace orchestration service; and The log is recorded in response to the determination.

10. The IHS of claim 1, wherein the operation sequence includes at least one of the following: configuring basic input / output system BIOS settings, installing applications, or executing security monitoring services.

11. A memory storage device having program instructions stored thereon, the program instructions causing the IHS to: when executed by an information processing system (IHS) that provides a workspace orchestration service: In response to determining that the connection with the local management agent has limited bandwidth or is unreliable, orchestration code is transmitted to the local management agent; After the workspace is instantiated by the local management agent, a copy of the logs recorded by the local management agent, which is extended to the Trusted Platform Module (TPM), is received. These logs and extended TPM measurements include: The orchestration code, and instructions for the sequence of operations performed by the local management agent during the instantiation of the workspace, wherein communication between the local management agent and the workspace orchestration service is limited or nonexistent during the instantiation process of the workspace; and A connection is established between the workspace and the workspace orchestration service in response to the successful completion of: (i) authentication of the orchestration code, and (ii) verification of the operation sequence.

12. The memory storage device of claim 11, wherein the program instructions, when executed, further cause the IHS to transmit a workspace definition to the local management agent, and wherein the local management agent is configured to instantiate the workspace using the workspace definition.

13. The memory storage device of claim 12, wherein the workspace definition includes at least one of the following: threat monitoring level, threat detection level, threat analysis level, threat response level, storage confidentiality level, network confidentiality level, memory confidentiality level, display confidentiality level, user authentication level, information technology (IT) management level, regulatory compliance level, local storage control level, central processing unit (CPU) access level, graphics card access level, application usage level, or application installation level.

14. The memory storage device of claim 11, wherein the extended measurements of the log-recorded code and sequence are encrypted and stored in a secure memory accessible by the TPM.

15. The memory storage device of claim 11, wherein the instantiation of the workspace is performed without any communication between the local management agent and the workspace orchestration service.

16. The memory storage device of claim 11, wherein the program instructions, when executed, further cause the IHS to: It is determined that the connection between the local management agent and the workspace orchestration service has limited bandwidth; and In response to the determination, the orchestration code is transmitted to the local management agent.

17. The memory storage device of claim 11, wherein the program instructions, when executed, further cause the IHS to: It was determined that the connection between the local management agent and the workspace orchestration service was intermittent; and In response to the determination, the orchestration code is transmitted to the local management agent.

18. The memory storage device of claim 11, wherein the program instructions, when executed, further cause the IHS to: It is determined that the local management agent is located behind a firewall relative to the workspace orchestration service; and In response to the determination, the orchestration code is transmitted to the local management agent.

19. The memory storage device of claim 11, wherein the operation sequence includes at least one of the following: configuring basic input / output system BIOS settings, installing applications, or executing security monitoring services.

20. A method performed by a local management agent, comprising: Receive workspace definitions from the workspace orchestration service; In response to determining that the connection to the workspace orchestration service has limited bandwidth or is unreliable, orchestration code is received from the workspace orchestration service; Instantiate the workspace based on the workspace definition; Record a log, the log including: the orchestration code, and an indication of the sequence of operations performed during the instantiation; After the instantiation of the workspace, a copy of the log is provided to the workspace orchestration service, wherein communication between the local management agent and the workspace orchestration service is limited or nonexistent during the instantiation process of the workspace; and A connection is established between the workspace and the workspace orchestration service in response to the successful completion of the following: (i) authentication of the orchestration code, and (ii) verification of the operation sequence.

Images