Granular secure user access to private resources

Abstract

Methods, systems, and computer program products are provided for granular secure user access to private resources. The increased granularity of security policies for user access may reduce security threats to resources. Security policies indicating user access to secure resources may be based on various combinations of user identity, client-side process (e.g., sub-process) identity, device identity, device type, device location, resource access type, smart access (e.g., selective traffic routing), etc. For example, the security policy may indicate that a user A using a computing device B executing a process C with a process signature S (e.g., signing a signature fingerprint, etc. The process identity may be indicated by at least one of a process name, a code signature, a fingerprint, a process version, or a process publisher. Resource access security policy determination and / or enforcement may be performed by a security client and / or a security engine (e.g., a SASE providing a ZTNA).

Description

Background Art

[0001] A large employee workforce works remotely. Employees access a variety of local and remote (e.g., cloud) company resources directly from the Internet, through an enterprise network (e.g., via a virtual private network (VPN) connection), or from a computing device within the enterprise network. Remote company resources may include services and applications available through Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Business Software as a Service (SaaS), Security as a Service (SECaaS), or Consumer SaaS. A large number of users accessing cloud resources may put a strain on network capacity and security stamps. Employees may access company resources in a branch office, for example, via a wide area network (WAN) connecting the corporate headquarters to the branch office, which may allow a compromised user / device (e.g., an attacker) to move laterally through the corporate network. Summary of the invention

[0002] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0003] Methods, systems, and computer program products are provided for granular secure user access to private resources. Increased granularity of security policies for user access enables reduction of security threats to resources. Security policies that direct user access to secure resources are based on various combinations of features such as user identity, client-side process identity, device identity, device type, device location, resource access type, smart access, etc. Resource access security policy determination and / or implementation is performed by a security client and / or server that provides security services (such as a security engine).

[0004] Other features and advantages of the present disclosure and the structure and operation of various embodiments are described in detail below with reference to the accompanying drawings. Note that the present disclosure is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Based on the teachings contained herein, additional embodiments will be apparent to those skilled in the relevant art. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present application and, together with the description, further serve to explain the principles of the embodiments and enable those skilled in the relevant art to make and use the embodiments.

[0006] Figure 1 A block diagram of an example computing environment for intelligent local access for zero-trust network access to private resources is shown in accordance with an embodiment.

[0007] Figure 2 A block diagram is shown of an example of intelligent local access for zero-trust network access to private resources with public service edge authentication and authorization, according to an embodiment.

[0008] Figure 3 A block diagram is shown of an example of intelligent local access for zero-trust network access to private resources with private service edge authentication and authorization, according to an embodiment.

[0009] Figure 4 A flow chart of an example method for intelligent local access for zero-trust network access to private resources is shown in accordance with an embodiment.

[0010] Figure 5 An example of a graphical user interface for granular secure access to private resources is shown in accordance with an embodiment.

[0011] Figure 6 A flow chart of an example method for granular secure access to private resources according to an embodiment is shown.

[0012] Figure 7 A block diagram of an example computing device is shown that may be used to implement example embodiments.

[0013] The features and advantages of the present disclosure will become more apparent through the detailed description set forth below in conjunction with the accompanying drawings, in which the same reference numerals always identify corresponding elements. In the accompanying drawings, the same reference numerals generally represent identical, functionally similar, and / or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost (multiple) digits in the corresponding reference numeral. DETAILED DESCRIPTION

[0014] I. Introduction

[0015] This specification and the accompanying drawings disclose one or more embodiments incorporating the features of the present disclosure. The scope of the present disclosure is not limited to the disclosed embodiments. The disclosed embodiments merely illustrate the present disclosure, and modified versions of the disclosed embodiments are also covered by the present disclosure. The embodiments of the present disclosure are defined by the appended claims.

[0016] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an example embodiment, it is within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0017] In the discussion, unless otherwise stated, adjectives such as "substantially" and "about" that modify conditions or relational characteristics of one or more features of the example embodiments of the present disclosure are understood to mean that the conditions or characteristics are defined within acceptable tolerances for the operation of the embodiment for its intended application.

[0018] If the performance of an operation is described herein as being "based on" one or more factors, it should be understood that the performance of the operation may be based only on such factor(s), or may be based on such factor(s) and one or more additional factors. Thus, as used herein, the term "based on" should be understood to be equivalent to the term "based at least on."

[0019] Many exemplary embodiments are described below. It should be noted that any section / subsection titles provided herein are not intended to be limiting. Embodiments are described throughout this document, and any type of embodiment may be included under any section / subsection. In addition, the embodiments disclosed in any section / subsection may be combined in any manner with any other embodiments described in the same section / subsection and / or different sections / subsections.

[0020] II. Example Implementation

[0021] Methods, systems, and computer program products are provided for granular secure user access to private resources. The increased granularity of security policies for user access reduces security threats to resources. Security policies that indicate user access to secure resources can be based on various combinations of user identity, client-side process (e.g., child process) identity, device identity, device type, device location, resource access type, smart access (e.g., selective traffic routing), etc. For example, a security policy can indicate that user A using computing device B to execute process C with process signature S (e.g., signing signature fingerprint, etc.) can access private resource D. The process identity can be indicated by at least one of a process name, a code signing signature, a fingerprint, a process version, or a process publisher. Resource access security policy determination and / or implementation is performed by a security client and / or a security engine (e.g., a SASE providing ZTNA).

[0022] A large employee workforce works remotely. Employees access a variety of local and remote (e.g., cloud) company resources directly from the Internet, through an enterprise network (e.g., via a virtual private network (VPN) connection), or from a computing device within the enterprise network. Remote company resources may include services and applications available through Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Business Software as a Service (SaaS), Security as a Service (SECaaS), or Consumer SaaS. A large number of users accessing cloud resources may put a strain on network capacity and security stamps. Employees may access company resources in a branch office, for example, via a wide area network (WAN) connecting the corporate headquarters to the branch office, which may allow a compromised user / device (e.g., an attacker) to move laterally through the corporate network.

[0023] When employees access the Internet from outside the company network, company network IT (Information Technology) administrators may not be able to monitor for viruses and malware. Administrators may not be able to identify compromised employee computing devices that can be used to access company resources. Compromised computing devices can be used to enter the company headquarters and extend attacks to other resources in the network, such as via email servers, financial applications, servers hosting the company's IP, etc.

[0024] A public service edge, such as a secure access service edge (SASE), can be implemented to improve the security of local and remote access to public and private resources. SASE can be implemented as a set of security services that enable network access. SASE can be used to provide network as a service (NaaS) and / or SaaS for managed cloud services. The SASE security layer can be proxied to one or more resources (e.g., such as Microsoft Azure). or IaaS / PaaS such as Amazon Web Services (AWS), Office Commercial SaaS applications such as , such as consumer SaaS applications), whether access is by a teleworker, remote operation (e.g., from a branch office), or from within the corporate network.

[0025] SASE can be implemented with ZTNA. ZTNA enables users to securely access private resources when the user is working off-site (e.g., remotely). Locally deployed users accessing private resources can be provided with high-performance access and the same security posture as off-site users. ZTNA achieves secure private access by providing application segmentation. Application segmentation provides protection against attacks due to lateral movement and provides per-application policies based on identity. In an example implementation of zero-trust-based access to private applications from users, user access granularity can be provided at the level of endpoints represented by Internet Protocol (IP) addresses or fully qualified domain names (FQDN)-port pairs. For example, ZTNA can be cheaper, easier to manage, high-performance, and scalable than locally deployed infrastructure that provides local proxies to authenticate and route traffic.

[0026] In contrast, VPN can provide direct access to a private network, while ZTNA can more securely proxy connections to specific private applications in a private network. ZTNA can be implemented with several principles. For example, ZTNA can be implemented to provide users with minimum permissions. In an example, a user can try to connect to an application. ZTNA can connect the user (e.g., if authenticated and authorized) to the application instead of to the entire network. ZTNA can be implemented by explicit verification of applications, networks, etc., which means or assumes no (zero) trust in the user. ZTNA can be implemented by assuming that access is an attack or damage that must be contained. For example, an employee's computing device (e.g., a machine) may be hacked or otherwise attacked. An attacker can use a machine to enter the company network. Accordingly, under the assumption that access is an attack, access can be limited or constrained. Metaphorically speaking, a key can be provided to access a single room, rather than an entire floor or building. ZTNA can be implemented to assume that a room key may be mistakenly or purposefully used for another room, and to prevent such use.

[0027] Authentication is the process of proving that a user or service is legitimate. Authentication can challenge a party (e.g., a user or service) for legitimate credentials (e.g., a username and a secret, such as a password), for example, as a basis for creating a security principal for identity and access control. Authorization is the act of granting permission to an authenticated security principal to do something. Authorization can specify what data a party (e.g., a user or service) is allowed to access and what the party can do with it.

[0028] The authentication information (e.g., credentials) provided by the user may include any information that can be used to verify the identity of the user. The credential categories may be summarized as something the user knows (e.g., answers to one or more prompts or questions, such as a username, password, etc.), something the user has (e.g., a device that receives a one-time code (OTC), a device that stores a password key, etc.), or something the user is (e.g., biometric information, such as a retinal scan, a facial scan, a fingerprint, etc.). Multi-factor authentication (MFA) may combine multiple types of credentials. A username may include any string, image (e.g., a pattern with encoded data), or information block. In an example, a username may include a random string, a cellular phone number, an email address, etc. A password may include any string and / or image (e.g., a pattern with encoded data). In an example, a password may include a one-time code (OTC) that is automatically sent during the login process to ensure that the entity logging in controls a device or account that may be specified during the creation of a user identity, such as a computing device or an account address.

[0029] ZTNA can be implemented with one or more ZTNA servers and ZTNA clients. Security policies for accessing resources (e.g., applications, networks) can be set on a security server (e.g., a ZTNA server) that provides a security service (e.g., a security engine). The ZTNA security service / engine can have a managed client layer that provides network security and access based on security policies. The security policy can indicate, for example, identity-based access to private networks and applications, private application discovery, allowed traffic (e.g., what type of traffic should pass through the managed client layer for customer resources), etc. The managed client layer can implement default or customer-specified security policies. The managed client layer can provide threat intelligence, perform deep packet inspection (DPS), traffic filtering, transport layer security (TLS) termination and inspection, cloud access security (e.g., data loss / information protection), a World Wide Web Application Firewall, etc. The managed client layer can be implemented to provide cloud services of NaaS and SaaS to one or more customers, and one or more customers can be individuals, enterprises, government entities, etc.

[0030] Security policies for accessing / connecting to private networks and / or applications may be managed by administrators (admins) for one or more resources accessed through the managed client layer (e.g., through a user interface provided by the ZTNA server). For example, an administrator of company A may set security policies for accessing company A's resources through the managed client layer, an administrator of company B may set security policies for accessing company B's resources through the managed client layer, and security policies for accessing customer owned, leased, etc. resources, and so on.

[0031] The customer's private network can be a combination of multiple networks. The customer's private network can have locally deployed applications and / or applications in the cloud. Some applications can be in one or more clouds (e.g., with different service operators such as Microsoft, Google, and Amazon).

[0032] For example, the managed client layer can control access / connection to networks and / or applications on one or more clouds (e.g., Microsoft Azure, Amazon Web Services (AWS), Google Cloud), and / or one or more private on-premises (e.g., enterprise) networks and / or applications (e.g., Web applications, remote server authentication access (such as Remote Desktop Protocol (RDP) or Secure Shell (SSH)) applications, transport protocols (such as Server Message Block (SMB) or File Transfer Protocol (FTP)) applications, enterprise applications (such as Systems, Applications, and Products (SAP) or PeopleSoft applications), printing, etc.) based on corresponding security policies.

[0033] The managed client layer can operate at the edge of the cloud service, for example, anywhere the cloud service can be accessed. The managed client layer can include one or more security engines, data traffic filtering, application of security policies to allowable traffic, etc. One or more security engines running in the managed client layer can implement security policies, such as user authentication and user authorization for access to resources, traffic filtering, traffic routing, etc. Traffic from authenticated and authorized users and / or computing devices can be provided to private networks and / or applications after the traffic passes inspection.

[0034] A connection can be established between a managed client layer and a managed service (e.g., an application) that the user / computing device is allowed to access. For example, a connector or proxy can create an outbound connection from an application to a managed client layer. Connectors can be deployed in various networks that users can access with applications through the managed client layer. Private access can be carried on outbound connections. For example, a flow can be established in an outbound connection for each application that a user is authorized to access and does access. A flow can encapsulate traffic in a tunnel. A connection can have multiple flows. Each flow can limit access to corresponding resources (e.g., similar to controlled access that limits access to a key to a specific room rather than to all rooms on an entire floor or building). A connector can forward incoming traffic to the intended application.

[0035] The user computing device may execute a client application. The client application may convert the user computing device into a managed client, for example, for accessing private resources, such as private resources of an employer. The user device may be referred to as a ZTNA client. The ZTNA client application running on the computing device may receive a security policy from a ZTNA server. The ZTNA client may route traffic from the computing device to a managed client layer (e.g., in a cloud service) based on the security policy. The security policy may indicate, for example, where the ZTNA client should route traffic to attempt to use a private application or network. The security policy may indicate that the user and / or device must first be authenticated, for example, by entering credentials for analysis and approval by the managed client layer. In an example, conditional access to managed services (e.g., networks, applications) based on security policies in the managed client layer may be implemented by Microsoft Azure Active Directory (AAD).

[0036] A connection between a ZTNA client and a managed client layer (e.g., at the cloud computing edge) may be established for authenticated and authorized users / computing devices. A flow may be established in the connection for each network and / or application accessed by the user. A connection may have multiple flows. Each flow may restrict access to a corresponding resource (e.g., similar to controlled access that restricts access to a key to a specific room rather than all rooms on an entire floor or building).

[0037] Embodiments may be implemented in a variety of systems / environments. For example, Figure 1 A block diagram of an example computing environment 100 for smart local access for zero-trust network access to private resources is shown according to an embodiment. Other examples of smart local access for zero-trust network access to private resources can be implemented.

[0038] like Figure 1 As shown, computing environment 100 may include private network 126, one or more computing devices 112 that may be used by users outside of the private network or other trusted network ((multiple) OTN users), one or more computing devices 136 that may be used by users 140 in the private network or other trusted network ((multiple) ITN users), public service edge 118, private service edge 134, one or more data centers 104, and one or more networks 116. Example computing environment 100 presents one of many possible examples of computing environments. Example computing environment 100 may include any number of computing devices and / or servers, such as Figure 1 Example components are shown and other additional or alternative devices not explicitly shown.

[0039] The network(s) 116 may include one or more public access and / or restricted access networks. The network(s) 116 may include, for example, any one or more of a local area network (LAN), a wide area network (WAN), a personal area network (PAN), a combination of communication networks such as the Internet, and / or a virtual network. In an example implementation, the computing device(s) 112, the data center(s) 104, the public service edge 118, and the private network, the private service edge 134, and the ITN computing device(s) 136 may be communicatively coupled via the network(s) 116. In an implementation, any one or more of the computing device(s) 112, the data center(s) 104, the public service edge 118, and the private network, the private service edge 134, and the ITN computing device(s) 136 may communicate via one or more application programming interfaces (APIs) and / or according to other interfaces and / or techniques. The computing devices 112, the data centers 104, the public service edge 118, and the private network, the private service edge 134, and the ITN computing devices 136 may include one or more network interfaces that enable communication between the devices. Examples of such wired or wireless network interfaces may include IEEE 802.11 wireless LAN (WLAN) wireless interfaces, Worldwide Interoperability for Microwave Access (Wi-MAX) interfaces, Ethernet interfaces, Universal Serial Bus (USB) interfaces, cellular network interfaces, Bluetooth interfaces, and the like. TM interface, near field communication (NFC) interface, etc. Other examples of network interfaces are described elsewhere herein.

[0040] The public service edge 118 and / or (multiple) data centers 104 may (e.g., each) include one or more computing devices, servers, services, local processes, remote machines, web services, etc. to provide one or more cloud-based and / or cloud edge services, such as cloud computing resources, NaaS, and / or SaaS (e.g., security services, such as user authentication, authorization, conditional access) to customers. The public service edge 118 and / or (multiple) data centers 104 may provide a managed client layer (e.g., as described herein) for (multiple) OTN computing devices 112 and / or (multiple) ITN computing devices 136. For example, a company with a private network may be a customer of a cloud / edge service provider of SaaS and / or NaaS. The company's workforce may include (multiple) OTN users 102 and (multiple) ITN users 140. (Multiple) data centers 104 (e.g., in a cloud) and a public service edge 118 (e.g., at the edge of a cloud) may include, for example, one or more authentication and authorization engines 106, 120, respectively, security policies 102, 122, respectively, and / or one or more security engines 110, 124, respectively. Figure 1The dashed boxes in show examples of components that may or may not be implemented in various examples, such as for component redundancy and load balancing.

[0041] In some examples, the authentication and authorization engine(s) / service(s) 120 may be implemented in the edge (e.g., private and / or public service edge 118, 114), for example, along with a security engine (e.g., ZTNA engine) 124. In some examples, components running in the edge may (e.g., may also) run in a data center to provide redundancy in the event that one or the other is overloaded or offline. In an example, the public service edge 118 may include the security engine(s) / service(s) 124 (e.g., SASE ZTNA), and may or may not include the authentication and authorization engine(s) 120 and security policy 122. In an example, the data center(s) 104 may include the authentication and authorization engine(s) 106 and security policy 108, and may or may not include the security engine(s) 110.

[0042] The authentication and authorization engine(s) 120, 106 (e.g., or as implemented in the private service edge 134) may be an identity platform (IdP), such as Microsoft Azure Active Directory (AAD). For example, the identity of the OTN user(s) 102 may be authenticated based on login credentials. Authorization to access the private resource(s) 132 may be granted or denied, for example, based on the security policies 108, 122. Security tickets (e.g., security ticket(s) 128) may be issued for authenticated users that are authorized to access the private resource(s) 132.

[0043] The public service edge 118 or (multiple) data servers 104 may be or may include a tunnel server, such as a remote procedure call (RPC) server. The tunnel server may be connected to the security client 114 interface, for example, via a data channel and a control channel. The tunnel server may communicate with (multiple) security engines 110, 124, for example, using a transmission control protocol (TCP). The tunnel server may be an open source RPC server that provides an extensible application programming interface (API). The tunnel server may provide traffic received from the security client 114 in (multiple) OTN computing devices 112 to (multiple) security engines 110, 124 (e.g., ZTNA engines). (Multiple) security engines 110, 124 may analyze traffic packets and apply security policies 108, 122 to traffic. For example, (multiple) security engines 110, 124 may check the requested certificate, header, IP address (e.g., determine whether it is a trusted IP), tenant, malware, intrusion, etc. If the traffic is OK, (multiple) security engines 110, 124 may send the packet to (multiple) connectors 130. In some examples, tunnels may be implemented between security engine(s) 110, 124 and connector(s) 130. In some examples, a tunnel path (e.g., RPC) path from a tunnel server may pass through one or more data centers to a locally deployed connector (e.g., connector(s) 130). In an example, a tunnel path may be from security engine(s) 110, 124 to an application proxy service in a data center to a connector (e.g., connector(s) 130) communicatively coupled to a locally deployed application (e.g., private resource(s) 132) in a private network 126.

[0044] The private network 126 may be a network with constrained access protected by a security system to allow authorized access to the private network 126 and / or (multiple) private resources 132 and deny unauthorized access to the private network 126 and / or (multiple) private resources 132. The (multiple) private resources 132 may be any type of resource, such as private resources in a cloud service, information / data, applications / programs, etc., as described herein. The private network 126 may be, for example, a cloud service, an enterprise network, or other network. Secure access to the private network 126 may be provided by a cloud service / cloud edge service. For example, the security system for the private network may be provided by one or more of a public service edge 118 outside the private network 126, a private service edge 134 inside the private network 126, and / or (multiple) data centers 104 outside the private network 126. The security system may issue (multiple) security tickets 128 to authenticated, authorized, and / or conditionally used users (e.g., (multiple) OTN users 102 and (multiple) ITN users 140). Security ticket(s) 128 may be associated with connector(s) 130 , for example, to manage access to and secure connection(s) to private resource(s) 132 .

[0045] The private service edge 134 may be a private implementation of the public service edge 118, for example, having the same or similar components (e.g., authentication and authorization engine(s), security policy, and / or security engine(s)). The private service edge 134 may be managed by the public service edge 118, for example, to provide a common security posture for the OTN user(s) 102 and the ITN user(s) 140. The private service edge 134 may maintain unified security while providing more efficient network routing for the ITN computing devices(s) 136. Traffic from the ITN computing devices(s) 136 may be routed to the connector(s) 130 to the private resource(s) 132 via the private service edge 134 without going to and passing through the public service edge 118 or the data center(s) 104. For example, local traffic from the ITN user(s) 140 may be routed locally to the connector(s) 130 to the private resource(s) 132 via the private service edge 134 within the private network 126.

[0046] In some examples, the public service edge(s) 118 or the data center(s) 104 (e.g., which may provide security redundancy) may be used to provide private network access security for the OTN user(s) 102 (e.g., users working from home) and the ITN user(s) 140 (e.g., users working in an office or satellite office where the private network 126 is located). In some examples, the private service edge 134 may (e.g., alternatively and / or additionally) be used to provide security for the ITN user(s) 140. The public service edge 118, the data center(s) 104, and / or the private service edge 134 may issue security tickets 128 for the authenticated, authorized OTN user(s) 102 and the ITN user(s) 140. The private network 126 may connect the private resource(s) 132 to the public service edge 118, the data center(s) 104, and / or the private service edge 134 via the connector(s) 130, for example, as described herein. The connector(s) 130 may forward traffic from the public service edge 118, the data center(s) 104, and / or the private service edge 134 to the private resource(s) 132. The public service edge 118, the data center(s) 104, and / or the private service edge 134 may connect to the OTN computing device(s) 112 and / or the ITN computing device(s) 136 and perform routing of traffic from / to the OTN computing device(s) 112 and / or the ITN computing device(s) 136 that have access to the private resource(s) 132.

[0047] The private service edge 134 can be implemented to improve network routing efficiency for local deployment users, for example, at the expense of hardware, software, setup, and maintenance. The private service edge software can be installed on one or more local deployment servers (for example, in the private network 126). The private service edge software can allow the private service edge 134 to be managed by the public service edge 118, which can be deployed off-site in or at the edge of the cloud. The private service edge utilizes one or more servers that involve establishment, management, etc. from a network administrator. In some examples, a separate security model can be implemented for local deployment access (for example, instead of a private service edge), but hardware (for example, servers), administrator setup, management, etc. can also be involved, resulting in uneven security postures for (multiple) OTN users 102 and (multiple) ITN users 140.

[0048] The OTN computing device(s) 112 and the ITN computing device(s) 136 may include computing devices used by one or more customers (e.g., individual users, home users, enterprise users, government users, administrators, etc.), generally referred to as the OTN user(s) 102 and the ITN user(s) 140. The OTN computing device(s) 112 and the ITN computing device(s) 136 may include one or more applications, operating systems, virtual machines (VMs), storage devices, etc., which may be executed, hosted, and / or stored in the OTN computing device(s) 112 and the ITN computing device(s) 136, or executed, hosted, and / or stored via one or more other computing devices via the network(s) 116. In an example, the OTN computing device(s) 112 and the ITN computing device 136 may access one or more other devices (e.g., via the network(s) 116), such as the data center(s) 104, the public service edge 118, the private network 126, the private service edge 134, etc., to request services (e.g., in a service request (SR)) and / or provide information, e.g., for user authentication, authorization, and continued conditional access to the private resource(s) 132.

[0049] OTN computing device(s) 112 and ITN computing device(s) 136 may represent any number of computing devices and any number and type of groups (e.g., various users among multiple cloud service tenants). OTN user(s) 102 and ITN user(s) 140 may represent any number of people who may or may not be authorized to access one or more private resources 132. OTN computing device(s) 112 and ITN computing device(s) 136 may each be any type of fixed or mobile computing device, including a mobile computer or a mobile computing device (e.g., devices, personal digital assistants (PDAs), laptops, notebook computers, such as the Apple iPad TM The computing device(s) 104 may be a tablet computer, a netbook, etc., a mobile phone, a wearable computing device, or other type of mobile device, or a fixed computing device such as a desktop computer or a PC (personal computer), or a server. The computing device(s) 104 are not limited to physical machines, but may include other types of machines or nodes, such as virtual machines. Figure 7 Examples of OTN computing device(s) 112 and ITN computing device 136 are shown in FIG.

[0050] In some examples, OTN computing device(s) 112 and ITN computing device(s) 136 may represent the same (e.g., portable) computing device(s) in different locations (e.g., inside private network 126 or other trusted network, and outside private network 126 or other trusted network). In some examples, OTN user(s) 102 and ITN user(s) 140 may represent the same user(s) in different locations (e.g., inside private network 126 or other trusted network, and outside private network 126 or other trusted network). For example, a user may use a portable computing device inside and outside private network 126.

[0051] The OTN computing device(s) 112 and the ITN computing device(s) 136 may (e.g., each) execute one or more processes. A process is an instance of an executable program. For example, the OTN computing device(s) 112 may execute one or more processes 113, and the ITN computing device(s) 136 may execute one or more processes 137. The one or more processes 113, 137 may be instances of one or more applications / programs for (e.g., attempting to) access the private network 126 and / or the private resource(s) 132. In some examples, the processes 113, 137 may be the same process, such as when a user uses a portable computing device inside and outside the private network 126.

[0052] The OTN computing device(s) 112 and the ITN computing device(s) 136 may (e.g., each) execute a security client. For example, the OTN computing device(s) 112 may execute the security client 114, and the ITN computing device(s) 136 may execute the security client 138. The security clients 114, 138 may each be, for example, a SASE ZTNA client. In some examples, the security clients 114, 138 may be the same security client, such as when a user uses a portable computing device inside and outside the private network 126. The security clients 114, 138 may be clients of the security engine(s) 124 (e.g., the SASE ZTNA engine(s)).

[0053] In some examples, a user (e.g., OTN user(s) 102 and / or ITN user(s) 140) may attempt to access a private application (e.g., private resource(s) 132) using a browser running as process(s) 113, 137 on a computing device (e.g., OTN computing device(s) 112 and / or ITN computing device 136). For example, process(es) 113, 137 may include a web browser that attempts to load the private application 132 as a web application. In some examples, the security client 114, 138 may include a NaaS client with network interception, for example, to intercept network requests. An example of a NaaS client is a ZTNA client. ZTNA, NaaS, and SaaS may be used interchangeably. A component of a ZTNA client may include a lightweight filter (LWF) driver. In an example, a network driver interface specification (NDIS) intermediate (IM) filter driver or an NDIS LWF driver may be used to implement network control or other related functions. The LWF driver may be implemented as a kernel component running on a computing device (e.g., OTN computing device(s) 112 and / or ITN computing device 136). The LWF driver may be implemented in a network stack to intercept traffic. For example, a user may type "bing.com" in a browser address bar. A request to bing.com may be intercepted by an LWF component in a security client 114, 138. The intercepted request may pass through the kernel to the networking stack. A security policy 122 may be applied to the intercepted traffic.

[0054] The security client (e.g., ZTNA client) 114, 138 may (e.g., also) include a private access plug-in component. The private access plug-in may tunnel traffic intercepted / captured by the network interception component to the (multiple) data center 104, the public service edge 118, and / or the private service edge 134. The security client 114, 138 (e.g., private access plug-in component) may have one or more control channels (e.g., to the (multiple) security engine and / or to the (multiple) authentication and authorization engine (s)) to the (multiple) data center 104, the public service edge 118, and / or the private service edge 134.

[0055] As described herein, a consistent security posture may be provided to users (e.g., OTN user(s) 102 and ITN user(s) 140) regardless of the user's location relative to a private network 126 or another trusted network without requiring additional infrastructure, setup, management, etc. The same security posture may be provided to users deployed locally and remotely with intelligent (e.g., variable) routing. Some security measures (such as traffic inspection and filtering) provided by the security engine(s) 110, 124 or in the private service edge 134 may or may not be implemented for local routing, although being located in a trusted network may provide an improved level of security relative to the OTN user(s) 102. The security client 138 in the ITN computing device(s) 136 may utilize the private service edge 134, the public service edge 118, and / or the data center(s) 104 for authorization, authentication, and / or ongoing conditional access to the ITN user(s) 140 while providing intelligent local access to the private resource(s) 132. For example, a security service (e.g., a secure access service edge (SASE) providing zero trust network access (ZTNA)) (e.g., private service edge 134, public service edge 118, and / or data center(s) 104) can maintain the same or similar security posture for users working remotely (e.g., deployed offsite or outside a private network or other trusted network) (e.g., OTN user(s) 102) and / or working locally (e.g., deployed locally or inside a private network or other trusted network) (e.g., ITN user(s) 140) by providing authentication, authorization, and / or ongoing conditional access via the security service (e.g., private or public SASE), while intelligently routing remote client traffic (e.g., from OTN computing device(s) 112) to private resource(s) 132 and routing local client traffic (e.g., from ITN computing device(s) 136) locally to private resource(s) 132 via the security service (e.g., private service edge 134, public service edge 118, and / or data center(s) 104). Traffic routing determinations may be made by a security client (e.g., security client 114, 138, which may be a ZTNA client) and / or a security server (e.g., security engine(s) 110, 124 or a security server in private service edge 134, which may be a ZTNA server). Traffic routing determinations may be based on the location of the client computing device, such as a trusted network detection indicating whether the client computing device (e.g., OTN computing device(s) 112 or ITN computing device(s) 136) is inside or outside the private network 126 and / or another trusted network (e.g., implemented with the same or similar security policies and / or services).Traffic routing determinations may be based on one or more conditions in addition to or instead of location, such as the type of private resource accessed by the client computing device and / or the process(es) 113 involved in the attempted access to the private resource(s) 132 .

[0056] In the example system process flow, location determination (e.g., trusted network detection) can be performed by the security client 114, 138 (e.g., ZTNA client) and / or by the private service edge 134, the public service edge 118, and / or the (multiple) data center 104. It can be determined whether the computing device 112, 136 is in the private network 136 or other trusted network based on the location determination (e.g., trusted network detection). The security client 114, 138, the private service edge 134, the public service edge 118, and / or the (multiple) data center 104 can apply security policies 108, 122 (e.g., or security policies in the private security edge 134), such as user authentication, authorization, and / or conditional access. The security policy 108, 122 (e.g., or security policies in the private security edge 134) can be based on one or more of the following: user identity, location, (multiple) process 113, 137, type of (multiple) private resource 132, etc. The security policy may be user identity aware, user and / or computing device location aware, private resource aware, computing device process aware, etc. Intelligent traffic routing may be based on one or more security policies.

[0057] In an example implementation of network detection, a TND policy may be enabled for location detection. A connector / agent may be deployed on a trusted network (e.g., locally deployed, such as in a private network 126). The connector / agent may be, for example, a (multiple) connector 130. The connector / agent may be configured (e.g., by an administrator) to expose endpoints, for example, continuously or on command, for example, by exposing an IP or configuring a DNS internally. One or more criteria may be indicated in a TND policy (e.g., making the FQDN locally available, which may only be reached by a secure client when the computing device is in a trusted network). The policy may indicate that a private network enables secure clients in locally deployed computing devices to perform intelligent local access. A secure client (e.g., a secure client 114, 138) may be configured to contact / detect exposed endpoints to determine whether a computing device (e.g., (multiple) computing devices 112, 136) is in a trusted network (e.g., a locally deployed network). In an example implementation of network detection (e.g., alternative and / or additional), a TND policy may be configured. An endpoint may be established / configured (eg, used) for a TND. For example, a connector agent may (eg, automatically detect) a trusted network and configure / perform settings without involving an administrator.

[0058] The security client may intelligently (e.g., selectively) route traffic from the user computing device based on one or more of: user identity, location, process type(s) 113, 137, private resource type(s) 132, etc. For example, the security client (e.g., security client 138) may intelligently (e.g., selectively) route traffic from the ITN computing device(s) 136 locally (e.g., rather than through the edge / cloud) to the private resource(s) 132 based on determining that the ITN computing device(s) 136 are located in the private network 126 (e.g., or other trusted network) and / or based on user identity-based security (such as authentication, authorization, and / or based on conditional access to the private resource(s) 132), and / or based on the process(es) 113, 137, and / or based on the type of the private resource(s) 132, etc.

[0059] The security client (e.g., security client 114) may, for example, based on determining that the OTN computing device(s) 112 are located outside the private network 126 (e.g., and outside other trusted networks), and / or based on user identity-based security (such as authentication, authorization, and / or conditional access to the private resource(s) 132), and / or based on the process(es) 113, 137, and / or based on the type of the private resource(s) 132, etc., intelligently (e.g., selectively) route traffic from the OTN computing device(s) 112 to the private resource(s) 132 via cloud / edge security (e.g., security engine(s) 110, 124). The data center(s) 104, the public service edge 118, and / or the private service edge 134 may provide continuous access assessment regardless of traffic routing determinations / decisions.

[0060] Figures 2 to 4 Examples of intelligent routing based on location determination alone or in combination with one or more other parameters (e.g., user identity type of process(es) 113, 137, type of private resource(s) 132, etc.) are shown. Other examples may be implemented in a variety of implementations with and without consideration of the location of the user and / or computing device(s). Figures 2 to 4 It is shown that after authentication and authorization, unlike computing devices outside a private network or other trusted network, traffic need not be tunneled to a managed client layer in a public service edge in all cases. Instead, based at least on one or more conditions or parameters, traffic can be sent locally by a secure client (e.g., a ZTNA client) on a computing device to a private application.

[0061] like Figures 1 to 4As shown, a public or private service edge with a managed client layer can provide authentication (e.g., for user identities), conditional access, authorization (e.g., allowing access for authorized user identities), continuous access evaluation (CAE), application segmentation for limiting access, traffic security (e.g., inspection, filtering), etc. After authentication, authorization, and segmented access to applications, the public or private service edge can continue to perform CAE and conditional access to locally deployed users / computing devices. Other forms of security (such as endpoint protection) can be implemented in a security client (e.g., a ZTNA client) for locally deployed users / computing devices in a private network. Security implemented for locally deployed computing devices can reduce the added value of one or more types of public service edge security, such as traffic security (e.g., inspection, filtering). The private network can (e.g., additionally and / or alternatively) inspect traffic leaving and entering the private network, traffic within the network, or traffic via the public or private service edge.

[0062] Conditional access security policies for authorized users can be based on various conditions, such as device location, time, IP address, etc. For example, access can be regulated (e.g., allowed, denied, double-checked (such as through multi-factor authentication), restricted) based on one or more detected conditions, such as the location of a computing device ostensibly used by an authorized user (e.g., various locations locally deployed or outside a private network, such as in another trusted network, at home, in a public place, etc.).

[0063] Intelligent (e.g., variable, selective, or conditional) traffic routing can be determined by the security client and / or the public / private service edge. The security client can implement the determination. Trusted Network Detection (TND) can be used to determine the user / computing device location (e.g., by the security client). The administrator can specify security policy criteria for determining the user / device location as entering or leaving the private network. The ZTNA client can, for example, route traffic in a tunnel to the public / private service edge (e.g., based on the location determination and / or command of the service edge) (e.g., for authorized users detected as being outside the network) and / or can route traffic locally (e.g., for authorized users detected as being inside the network / locally deployed). Conditional traffic routing can result in conditional traffic security monitoring, conditional use of connectors, conditional connections between private networks and service edges, conditional use of connectors in private networks, and the like.

[0064] Intelligent traffic routing determination may reside in whole or in part in a security client. A security client may implement / implement traffic routing determination. Traffic routing decisions based on one or more security policies, such as client location determination (e.g., based on one or more trusted network detection criteria), may be made in a client or an engine (server). The security engine may provide security policies to the client to the security client. In some examples, the client may share its state with the security engine / server, and the server may apply the security policy, determine the route, and then instruct the client to take action based on the determination. The server may send a (e.g., new) policy to the client, which may be a temporary policy or a session-based policy for implementing traffic routing. In some examples, the client may apply a security policy (e.g., provided by a server) to the determined state of the client, for example, to determine the route and then implement the route determination.

[0065] In some examples, routing determinations, such as whether to perform remote routing of client traffic (using packet inspection) or local routing (no inspection), can be based on one or more security policies, parameters, and / or conditions. Traffic policy evaluation (TPE) can determine client traffic routing (e.g., remote routing or local routing of traffic). TPE can be configured to determine routing based on evaluating any number of security policies, parameters, and / or conditions, such as one or more of the following: identity authentication policy, identity authorization policy, user / device location determination policy, trusted network detection (TND) determination policy, type of application accessed based on application classification policy (e.g., highly confidential applications, risky applications), etc. In some examples, routing can be based on the type of application and / or information expected in the traffic. For example, access to highly confidential applications and / or highly confidential information can be routed differently from access to public applications with public information. Network resource administrators can specify (e.g., set) and manage security policies, for example, in a user interface. Policies can be accumulated in a policy table. For example, entries in the policy table may indicate specific applications, their IP addresses, routing instructions (e.g., bypass-no tunnel, remote / cloud / edge, or local). The TPE may implement alternative and / or additional logic to determine routing based on any number of policies, parameters, and / or conditions. Additional policies, parameters, and / or conditions may include, for example, a location in a trusted network to allow local routing.

[0066] Figure 2 A block diagram of an example of intelligent local access for zero-trust network access to private resources using public service edge authentication and authorization according to an example embodiment is shown. For simplicity, Figure 2 The diagram shows the absence of network(s) 116 and data center(s) 104. Figure 1 . Various implementations can be used with Figure 2The examples shown are the same, similar, or different, and may or may not include network(s) 116 and datacenter(s) 104 .

[0067] like Figure 2 As shown in the example of , an off-site computing device outside of a private network (e.g., or other trusted network) can perform intelligent access by sending traffic to private resources via a public edge in the cloud. For example, a security client 114 in the (multiple) OTN computing device 112 can seek remote authentication and authorization (RAA) 202 from a public service edge 118. The security client 114 in the (multiple) OTN computing device 112 can seek authentication and / or application of security policies (e.g., remote continuous access evaluation) RCAE 202) (e.g., initial, ongoing) from the (multiple) cloud / edge / off-site / public server (e.g., public service edge 118) regardless of public / private traffic routing, for example, to provide the same security posture to users accessing private resources locally and remotely, while intelligently routing traffic locally if / when authorized. The (multiple) authentication and authorization engine 120 can authenticate and authorize the (multiple) OTN user 102 to access the (multiple) private resource 132 based on the security policy 122. In other examples, the authentication and authorization engine(s) 106 in the data center(s) 104 may perform authentication, authorization, and / or ongoing conditional access based on the security policy 108 .

[0068] The security client 114 may perform location detection (e.g., trusted network detection). Such location determination may be performed by the security client 114 in a variety of ways, including through location indications in profile information, an IP (Internet Protocol) address of the security client 114, a GPS (Global Positioning System), cellular tower triangulation, and / or any other suitable location determination technology. The security client 114 may determine that the OTN computing device(s) 112 are located outside the private network 126 (e.g., and other trusted networks). The security client 114 may intelligently route traffic from the process(es) 113 to the private resource(s) 132 through the public service edge 118 based on location detection and off-site deployment determinations. For example, traffic from the process(es) 113 that may be intercepted by the security client 114 may be sent (e.g., via remote traffic routing 204, such as through the network(s) 116 and / or the data center(s) 104) to the security engine(s) 124. The security engine(s) 124 may perform one or more analyses (e.g., based on the security policy 122) on the traffic 206 that passes the inspection before sending it to the connector(s) 130. The connector(s) 130 may provide the received traffic 210 to the private resource(s) 132 (e.g., based on the security ticket(s) 128 that confirms access by the OTN user(s) 102). The connector(s) 130 may verify access to the private resource(s) 132 based on access 208 to the (e.g., cached) security ticket(s) 128, which may be generated and provided by the security engine(s) 124. Intelligent access (e.g., selectable or variable) traffic routing may be implemented in reverse, for example, for traffic from the private resource(s) 132 to the process(es) 113.

[0069] like Figure 2As shown in the example of , a locally deployed computing device inside a private network (e.g., or other trusted network) can perform intelligent access by sending traffic to private resources locally without going through the public edge in the cloud. For example, the security client 138 in the (multiple) ITN computing device 136 can seek remote authentication and authorization (RAA) 214 from the public service edge 118. The security client 138 in the (multiple) ITN computing device 136 can seek the application of authentication and / or security policies (e.g., RCAE 214) (e.g., initial, ongoing) from the (one or more) cloud / edge / off-site deployment / public server (e.g., public service edge 118), regardless of public / private traffic routing, for example, to provide the same security posture to users accessing private resources locally and remotely, while intelligently routing traffic locally if / when authorized. The (multiple) authentication and authorization engine 120 can authenticate and authorize the (multiple) ITN user 140 to access the (multiple) private resource 132 based on the security policy 122. In other examples, the authentication and authorization engine(s) 106 in the data center(s) 104 may perform authentication, authorization, and / or ongoing conditional access based on the security policy 108 .

[0070] The security client 138 may perform location detection (e.g., trusted network detection). The security client 138 may determine that the ITN computing device(s) 136 are located inside the private network 126 (e.g., or another trusted network). The security client 138 may intelligently and locally route traffic from the process(es) 137 to the private resource(s) 132 based on the location detection and the offsite deployment determination. For example, traffic from the process(es) 137 that may be intercepted by the security client 138 may be sent locally (e.g., via local traffic routing 212) to the private resource(s) 132. Intelligent access (e.g., selectable or variable) traffic routing may be implemented in reverse, for example, for traffic from the private resource(s) 132 to the process(es) 136.

[0071] Figure 3 A block diagram of an example system 300 configured for intelligent local access with zero-trust network access to private resources using private service edge authentication and authorization is shown in accordance with an example embodiment. Figure 3 The diagram shows the absence of network(s) 116 and data center(s) 104. Figure 1 . Various implementations can be used with Figure 3 The examples shown are the same, similar, or different, and may or may not include network(s) 116 and datacenter(s) 104 .

[0072] like Figure 3As shown in the example of , an off-site computing device outside of a private network (e.g., or other trusted network) can perform intelligent access by sending traffic to private resources via a public edge in the cloud. For example, a security client 114 in (multiple) OTN computing devices 112 can seek remote authentication and authorization (RAA) from a public service edge 118. Application of authentication and / or security policies (e.g., initial, ongoing) can be performed by (multiple) cloud / edge / off-site / public servers, regardless of public / private traffic routing, for example, to provide the same security posture to users accessing private resources locally and remotely, while intelligently routing traffic locally if / when authorized. (Multiple) authentication and authorization engines 120 can authenticate and authorize (multiple) OTN users 102 to access (multiple) private resources 132 based on security policies 122. In other examples, (multiple) authentication and authorization engines 106 in (multiple) data centers 104 can perform authentication, authorization, and / or ongoing conditional access based on security policies 108.

[0073] The security client 114 may perform location detection (e.g., trusted network detection). The security client 114 may determine that the OTN computing device(s) 112 are located outside of the private network 126 (e.g., and other trusted networks). The security client 114 may intelligently route traffic from the process(es) 113 to the private resource(s) 132 through the public service edge 118 based on the location detection and the off-site deployment determination. For example, traffic from the process(es) 113 that may be intercepted by the security client 114 may be sent (e.g., via the remote traffic routing 204, such as through the network(s) 116 and / or the data center(s) 104) to the security engine(s) 124. The security engine(s) 124 may perform one or more analyses (e.g., based on the security policy 122) on the traffic before sending the inspected traffic 206 to the connector(s) 130. The connector(s) 130 may provide received traffic 210 to the private resource(s) 132 (e.g., based on the security ticket(s) 128 confirming access by the OTN user(s) 102). Intelligent access (e.g., selectable or variable) traffic routing may be implemented in the reverse direction, e.g., for traffic from the private resource(s) 132 to the process(es) 113.

[0074] like Figure 3As shown in the example of , a locally deployed computing device inside a private network (e.g., or other trusted network) can perform intelligent access by sending traffic to private resources locally without traversing the public edge in the cloud. For example, a security client 138 in the (multiple) ITN computing device 136 can seek remote authentication and authorization (RAA) 314 from the private service edge 134. The security client 138 in the (one or more) ITN computing devices 136 can seek (e.g., initial, ongoing) application of authentication and / or security policies (e.g., RCAE 214) from the private service edge 134, for example, to provide the same security posture to users accessing private resources locally and remotely, while intelligently routing traffic locally if / when authorized. The (multiple) authentication and authorization engine in the private service edge 134 can authenticate and authorize the (multiple) ITN users 140 to access the (multiple) private resources 132 based on the security policies in the private service edge 134.

[0075] The security client 138 may perform location detection (e.g., trusted network detection). The security client 138 may determine that the ITN computing device(s) 136 are located inside the private network 126 (e.g., or another trusted network). The security client 138 may intelligently and locally route traffic from the process(es) 137 to the private resource(s) 132 based on the location detection and the offsite deployment determination. For example, traffic from the process(es) 137 that may be intercepted by the security client 138 may be sent locally (e.g., via local traffic routing 312) to the private resource(s) 132. Intelligent access (e.g., selectable or variable) traffic routing may be implemented in reverse, for example, for traffic from the private resource(s) 132 to the process(es) 136.

[0076] Figure 4 A flow chart of an example method 400 for smart local access to zero-trust network access to private resources is shown according to an example embodiment. The embodiments and other embodiments disclosed herein may operate according to the example method 400. The method 400 includes steps 402-416. However, other embodiments may operate according to other methods. Based on the foregoing discussion of the embodiments, other structural and operational embodiments will be apparent to those skilled in the relevant art. No steps are required unless expressly indicated or inherently required. No order of steps is required unless expressly indicated or inherently required. No method embodiment is required to implement Figure 4 All steps shown. In various embodiments, steps may be added, removed, implemented alternatively, such as in any combination or order. Figure 4 This is just one of many possible embodiments. Embodiments may implement fewer, more, or different steps.

[0077] like Figure 4 As shown, in step 402, user identity credentials may be provided (e.g., by a client computing device having a secure client) to a server (e.g., a cloud or edge service) that provides secure access to resources on a private network. Figure 2 As shown, the (multiple) ITN computing devices 136 having the security client 138 and the (multiple) OTN computing devices 112 having the security client 114 can provide the user identity credentials of the (multiple) ITN users 140 and the (multiple) OTN users 102 to the server providing the public service edge 118, which provides secure access to the (multiple) private resources 132 in the private network 126.

[0078] like Figure 4 As shown, in step 404, at least one security policy may be applied (e.g., by a server having a security service) based on the user identity credentials to determine whether to allow a user associated with the user identity credentials to access resources in the private network. Figure 2 As shown, the authentication and authorization engine(s) 120 may apply the security policy 122 to determine whether the ITN user(s) 140 may use the process(es) 137 executed by the ITN computing device(s) 136, and whether the OTN user(s) 102 may use the process(es) 113 executed by the OTN computing device(s) 112 to access the private resource(s) 132 in the private network(s) 126.

[0079] like Figure 4 As shown, in step 406, the location of at least one of the user and the client computing device may be determined. Figure 2 As shown, the security client 138 and / or the security engine(s) 124 may determine the location of the ITN user(s) 140 and / or the ITN computing device(s) 136 relative to the private network 126 and / or another trusted network, and the security client 114 and / or the security engine(s) 124 may determine the location of the OTN user(s) 102 and / or the OTN computing device(s) 112 relative to the private network 126 and / or another trusted network.

[0080] like Figure 4 As shown, in step 408, the type of resource may be determined. Figure 2 As shown, the security client 138 , 114 and / or the security engine(s) 124 may determine the type of the private resource(s) 132 .

[0081] like Figure 4As shown, in step 410, a determination may be made (e.g., based at least on at least one of the determined location and type of resource): whether to route traffic from the client computing device within the private network to a resource in the private network or to route traffic outside the private network through a security service. Figure 2 As shown, the security client 138 and / or the security engine(s) 124 may determine (e.g., based on at least one of the determined location and type of resource) whether to route traffic from the ITN computing device(s) 136 to the private resource(s) 132 within the private network 126 or to route traffic outside the private network 126 through the security engine(s) 124. Similarly, the security client 114 and / or the security engine(s) 124 may determine whether to route traffic from the ITN computing device(s) 136 to the private resource(s) 132 within the private network 126 or to route traffic outside the private network 126 through the security engine(s) 124.

[0082] like Figure 4 As shown, in steps 412-416, if the location is in a private network or other trusted network and / or if the resource is of a first type, a determination may be made to route traffic from the client computing device locally, or if the location is outside of the private network or other trusted network and / or if the resource is of a second type, a determination may be made to route traffic from the client computing device to a secure service. Figure 2 As shown, if the location of the ITN computing device(s) 136 is within the private network 126 or other trusted networks and / or if the private resource(s) 132 are of the first type, the security client 138 may determine to route traffic from the ITN computing device(s) 136 locally within the private network 126 to the private resource(s) 132. Similarly, if the location of the OTN computing device(s) 112 is outside the private network 126 and other trusted networks and / or if the private resource(s) 132 are of the second type, the security client 114 may determine to route traffic from the OTN computing device(s) 112 remotely outside the private network 126 via the security engine(s) 124.

[0083] Application-to-application (e.g., workload-to-workload) security is different from user-to-application security (e.g., client-side to server-side access). The security policies 108, 122 that may (e.g., also) exist on the (multiple) OTN computing devices 112, (multiple) ITN computing devices 136, and / or the private service edge 134 may be used to implement user-to-application security (e.g., client-side to server-side access).

[0084] A private network / resource administrator (admin) can create and manage security policies 108, 122, etc., for example, using a graphical user interface (GUI) provided by the public service edge 118, (multiple) data centers 104, the private service edge 134, the security clients 114, 138, etc. The administrator can specify that access to various private resources be granted and / or denied. Security policies can segment one or more resources (e.g., applications) from a network, which can be referred to as resource / application segmentation. Application segmentation (e.g., in ZTNA) can authorize a user to access an application rather than the (e.g., the entire) network. Application segmentation is not process-specific. Various processes can be used to access private resources (e.g., applications), such as different browser processes (e.g., Microsoft Windows, developed by Microsoft Corporation of Redmond, Washington). Mozilla, developed by Mozilla Corporation in Mountain View, California Developed by Apple Inc. in Cupertino, California and Mountain View, California Chrome, etc.) or any other application executed by the computing device. For example, the security client 114 in the (multiple) OTN computing device 112 can (e.g., based on user authentication and authorization) send traffic from any of the various processes 113 executed by the (multiple) OTN computing device 112 to the (multiple) security engine 124 in the public service edge 118 via a tunnel, and the security engine 124 can (e.g., after inspecting the traffic) forward the traffic to the (multiple) connector 130, which can forward the traffic to the (multiple) private resource 132.

[0085] The granularity of secure access to private resource(s) 132 may be improved (e.g., through alternative and / or additional segmentation). For example, an administrator may specify (e.g., create, manage, control, constrain, etc.) access security policies for private network 126 and / or private resources 132 (e.g., or specify the absence of such security policies) based on one or more of: user identity, user / client-side device identity, user / client-side device location, client-side process identity, client device type, access type (e.g., based on client device location), date(s), time(s), intelligent routing (e.g., selective traffic routing), connector groups, port ranges, etc.

[0086] An advantage / benefit of improved security granularity may be reduced security threats. Increased access security granularity on the user side (e.g., user side process level granularity), which may be referred to as micro-segmentation, may significantly reduce security threats to access server side resources. For example, if a machine is compromised, an attacker may be prevented from sending traffic to private resources, for example, because only traffic from a specified process with a specified signature is allowed. Changing the process changes the signature of the process communicating with the private resource(s) 132, so traffic sent by the attacker will be blocked.

[0087] Figure 5 An example of a graphical user interface for granular secure access to private resources according to an example embodiment is shown. A network / resource administrator can use a private resource security policy menu 500 to create and / or manage security policies 108, 122 for (multiple) private resources 132. As shown, the administrator can specify private resources and access management for private resources, which can include user identities, process identities, port ranges, etc.

[0088] Private resource security policy menu 500 is one of many possible examples. Embodiments disclosed herein and other embodiments can operate according to example security policy menu 500 and / or other other menus. Based on the foregoing discussion of the embodiments, other structures and operation embodiments will be apparent to those skilled in the art. Unless explicitly indicated or inherently required, the interfaces or operations, steps or other uses of the interfaces shown in example menu 500 are not necessary. Unless explicitly indicated or inherently required, the order of operations or other uses of the interfaces in example menu 500 are not necessary. It is not required that the embodiments implement all interfaces shown in example menu 500. In various embodiments, interfaces can be added, removed, replaced / implemented in an alternative manner (e.g., in any combination or order). Example menu 500 is only one of many possible embodiments. Embodiments can implement fewer, more or different interfaces.

[0089] like Figure 5 As shown, the security administrator can describe one or more private resources in interfaces 502-506 (e.g., for zero or more security policies). For example, in interface 502, the administrator can indicate the name(s) of the private resource(s) 132 (e.g., application(s). In interface 504, the administrator can indicate the type(s) of the private resource(s) 132 (e.g., Web application). In interface 506, the administrator can indicate the source(s) of the private resource(s) 132, for example, by indicating an IP address, an IP range, an IP prefix, a fully qualified domain name (FQDN), a domain name, etc.

[0090] like Figure 5As shown, the security administrator can describe access management for one or more resources described in interfaces 502-506 in interfaces 508-516. For example, in interface 508, the administrator can indicate whether client access to the specified (multiple) private resources 132 is managed or unmanaged. In interface 510, the administrator can indicate (multiple) connector groups (e.g., default-North America) to connect to (multiple) private resources 132. In interface 512, the administrator can indicate (multiple) access types (e.g., local / local deployment, remote / off-site deployment, proxy) to (multiple) private resources 132. In interface 514, the administrator can indicate conditions for intelligent access / traffic routing from (multiple) client computing devices 112, 136 to (multiple) private resources 132. In interface 516, the administrator can indicate whether access is based on user identity and / or process identity. For example, the administrator can indicate in interface 518 that access is based on both user identity and process identity.

[0091] like Figure 5 As shown, the security administrator can describe user identities in interface 518 to indicate one or more users that are allowed to access one or more resources described in interfaces 502-506. For example, in interface 518, the administrator can indicate (multiple) users or (multiple) user groups that are allowed to access (multiple) resources. The default (e.g., no input) can be, for example, a default user group, all users of the private network 126, or no user.

[0092] like Figure 5 As shown, the security administrator can describe process identities in interfaces 520-526 to describe the identities of one or more processes that are allowed to access one or more resources described in interfaces 502-506. For example, in interface 520, the administrator can indicate the (multiple) client process (e.g., child process) names of the processes that are allowed to access (multiple) private resources 132. In interface 522, the administrator can indicate (multiple) process signatures (e.g., hashes or signing certificate fingerprints) of the client-side process. In interface 524, the administrator can indicate one or more process versions of the client-side process. In interface 526, the administrator can indicate one or more process publishers of the client-side process.

[0093] like Figure 5 As shown, the security administrator can describe the port range for accessing the private resource(s) 132 in interfaces 528 and 530. For example, in interface 528, the administrator can indicate whether the port range is provided for a connection-oriented logical port (e.g., TCP) or a connectionless-oriented logical port (e.g., User Datagram Protocol (UDP)). In interface 530, the administrator can indicate the port range of the TCP or UDP port indicated in interface 528.

[0094] like Figure 5 As shown in the example in , customization can be allowed in the security policy GUI. The security administrator can link server-side security with process-level segmentation on the user side. Private resource access security policies can have fine granularity, such as user-side process-level granularity. For example, a micro-segmented security policy can indicate what can access (multiple) private resources 132 (e.g., segmented applications that can be defined in the example menu 500). (Multiple) private resources 132 (e.g., (multiple) applications) can be referred to as destinations or targets of access. A micro-segmented security policy (e.g., specified for one or more users and / or computing devices) can indicate which process(es) 113, 137 can be used to access (multiple) private resources 132. For example, a process can be indicated by specifying a binary / executable file (e.g., *.exe) and / or by other indications of the process. The process signature can be a digital signature of an application with a fingerprint (e.g., a key identifier).

[0095] The same user using one or more different processes can have different access permissions to the private resource(s) 132. In some examples, an application can be (e.g., defined or specified as) a combination of one or more process (e.g., binary) names and / or one or more sub-process names, for example, by one or more of: one or more code signing signatures (e.g., fingerprints), a version of the binary, a publisher, etc. In various embodiments, the private resource(s) can include first-party and / or third-party applications.

[0096] The security policy may be based on how the process is executed or the environment in which the process is executed. For example, an application may run in a trusted mode or an untrusted mode, which may be different processes identified by different signatures (e.g., a first signature for an application running in an untrusted mode and a second signature for an application running in a trusted mode).

[0097] In some examples, a security policy may indicate that a user A using a computing device B executing process(es) (e.g., and / or subprocess(es)) C may access a private resource D (e.g., a private application). A security policy may describe a client-side process by a specific code signing signature. In some examples, a security policy may indicate that a user A using a computing device B executing process C having a process signature S (e.g., a signing signature fingerprint, etc.) may access a private resource D.

[0098] In some examples, traffic may be routed based on user-side process segmentation. For example, a security administrator may define an application with a specific binary file and indicate a route from a security client as local or remote (e.g., via a security engine) to (multiple) private resources 132. Security policies may be entered and / or presented in a policy table, which may indicate multiple private resources and available or selected security policies for each private resource, which may include bypass, local routing, edge routing, etc.

[0099] Security policy application / enforcement (e.g., micro-segmentation security policy enforcement) can be performed by a security client and / or a security engine. For example, a security client 114 can obtain details about process(es) 113 that may or may not be provided to security engine(s) 124. A security client 113 and / or security engine(s) 124 can determine whether traffic generated by process(es) 113 is sent to a public service edge 118 and / or whether public service edge 118 forwards traffic to connector(s) 130. Similarly, a security client 138 can obtain details about process(es) 137 that may or may not be provided to security engine(s) 124 or a security engine in a private service edge 134 or data center(s) 104. The security client 138 and / or security engine(s) 124 (or a security engine in a private service edge 134 or data center(s) 104) can determine, based on details about the process(es) 137, whether traffic generated by process(es) 137 should be sent to the public service edge 118, the private service edge 134, the data center(s) 104, or the private resource(s) 132, and / or whether the public service edge 118, the private service edge 134, or the data center(s) 104 forwards the traffic to the connector(s) 130 or the private resource(s) 132.

[0100] In various examples, the security client 114, 138 or a security engine in a public / private service edge 118, 134 or (multiple) data center 104 can implement the security policy determination. In some examples, the security client 114 or 138 can implement the security policy determination for efficiency (e.g., to avoid sending traffic using bandwidth that would otherwise be denied by the public service edge 118, the private service edge 134, or (multiple) security engines in the data center 114). In some examples, the security client 138 can implement the security policy determination based on intelligent access routing (e.g., allowed in the interface 514) and location determination (e.g., trusted network detection), for example, to perform local access routing of traffic from the process (multiple) 137 to the private resource (multiple) 132.

[0101] Figure 6A flow chart of an example method 600 for granular secure access to private resources according to an example embodiment is shown. The embodiments disclosed herein and other embodiments may operate according to the example method 600. The method 600 includes steps 602-610. However, other embodiments may operate according to other methods. Based on the foregoing discussion of the embodiments, other structural and operational embodiments will be apparent to those skilled in the relevant art. No step is required unless expressly indicated or inherently required. No order of steps is required unless expressly indicated or inherently required. It is not required that the method embodiments be implemented in a manner that is consistent with the present invention. Figure 6 All steps shown. In various embodiments, steps may be added, removed, or alternatively implemented, such as in any combination or order. Figure 6 This is just one of many possible embodiments. Embodiments may implement fewer, more, or different steps.

[0102] like Figure 6 As shown, in step 602, the user identity of the user using the client computing device is determined. Figure 1 As shown, the security client 114 may determine or receive user identity credentials of the OTN user(s) 102. The public service edge 118 may receive the user identity from the security client 114.

[0103] like Figure 6 As shown, in step 604, the process identity of the process executed by the client computing device is determined. Figure 1 As shown, the security client 114 can determine the one or more process identities of the (multiple) processes 113 by itself, or can receive the one or more process identities of the process 113, and the security client 114 determines the one or more process identities of the process 113 as the one or more process identities. The public service edge 118 can receive the one or more process identities from the security client 114.

[0104] like Figure 6 As shown, in step 606, an indication of at least one security policy indicating whether the combination of the user identity and the process identity authorizes the client computing device to use the private resource is received. Figure 5As shown, the security administrator may provide an indication of at least one security policy for access to private resource(s) 132 by OTN user(s) 102 using process(es) 113, which may include indicating in interface 516 that access is based on both user identity and process identity. The indication of at least one security policy may be received by a security engine in public service edge 118, private service edge 134, or data center(s) 104, or a security client in OTN computing device(s) 112 or ITN computing device 136. The indication of at least one security policy may be stored in, for example, security policies 108, 122.

[0105] like Figure 6 As shown, in step 608, a determination is made as to whether the combination of the user identity and the process identity authorizes the client computing device to use private resources in the private network (e.g., based on at least one security policy). Figure 1 As shown, a security engine in the public service edge 118 (e.g., security engine(s) 124), a security engine in the private service edge 134, or a security engine in the data center(s) 104 (e.g., security engine(s) 110), or a security client in the OTN computing device(s) 112 (e.g., security client 114), or a security client in the ITN computing device(s) 136 (e.g., security client 138) can make or receive an access determination (e.g., based on at least one security policy) indicating whether a combination of a user identity and a process identity authorizes the client computing device to use a private resource 132 in the private network 126.

[0106] like Figure 6 As shown, in step 610, an access determination may be performed. Figure 1 As shown, a security engine in the public service edge 118 (e.g., security engine(s) 124), a security engine in the private service edge 134, or a security engine in the data center(s) 104 (e.g., security engine(s) 110), or a security client in the OTN computing device(s) 112 (e.g., security client 114) or a security client in the ITN computing device(s) 136 (e.g., security client 138) can implement access determination. The implementation of the security client can reduce unnecessary traffic on the network(s) 116 as well as the implementation at the security engine in the public service edge 118 (e.g., security engine(s) 124), the security engine in the private service edge 134, or the security engine in the data center(s) 104 (e.g., security engine(s) 110).

[0107] III. Example Computing Device Embodiments

[0108] As described herein, the described embodiments and any modules, components and / or subcomponents thereof and the flowcharts / flowcharts (including portions thereof) and / or other embodiments described herein may be implemented in hardware or any combination of hardware and software and / or firmware, including as computer program code configured to be executed in one or more processors and stored in a computer-readable storage medium, or as hardware logic / circuitry, such as together in a system on a chip (SoC), a field programmable gate array (FPGA), and / or an application specific integrated circuit (ASIC). A SoC may include an integrated circuit chip including one or more of a processor (e.g., a microcontroller, a microprocessor, a digital signal processor (DSP), etc.), a memory, one or more communication interfaces, and / or other circuits and / or embedded firmware for performing its functions.

[0109] Figure 7 An exemplary implementation of a computing device 700 in which example embodiments may be implemented is shown. Consistent with all other descriptions provided herein, the description of computing device 700 is a non-limiting example for purposes of illustration. Example embodiments may be implemented in other types of computer systems, as known to those skilled in the relevant art.

[0110] like Figure 7 As shown, computing device 700 includes one or more processors (referred to as processor circuit 702), system memory 704, and bus 706 that couples various system components including system memory 704 to processor circuit 702. Processor circuit 702 is an electrical and / or optical circuit implemented as a central processing unit (CPU), microcontroller, microprocessor, and / or other physical hardware processor circuit in one or more physical hardware circuit device elements and / or integrated circuit devices (semiconductor material chips or dies). Processor circuit 702 can execute program codes stored in computer-readable media, such as program codes of operating system 730, application programs 732, other programs 734, etc. Bus 706 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of various bus architectures. System memory 704 includes read-only memory (ROM) 708 and random access memory (RAM) 710. Basic input / output system 712 (BIOS) is stored in ROM 708.

[0111] The computing device 700 also has one or more of the following drives: a hard disk drive 714 for reading and writing to a hard disk, a disk drive 716 for reading and writing to a removable disk 718, and an optical drive 720 for reading and writing to a removable optical disk 722 such as a CD ROM, DVDROM or other optical media. The hard disk drive 714, the disk drive 716 and the optical drive 720 are connected to the bus 706 via a hard disk drive interface 724, a disk drive interface 726 and an optical drive interface 728, respectively. The drive and its associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable disk and a removable optical disk are described, other types of hardware-based computer-readable storage media can be used to store data, such as flash memory cards, digital video disks, RAM, ROM and other hardware storage media.

[0112] A plurality of program modules may be stored on a hard disk, a magnetic disk, an optical disk, a ROM or a RAM. The programs thereof include an operating system 730, one or more application programs 732, other programs 734 and program data 736. The application program 732 or other program 734 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing the example embodiments described herein.

[0113] A user may enter commands and information into the computing device 700 through input devices such as a keyboard 738 and a pointing device 740. Other input devices (not shown) may include a microphone, a joystick, a game pad, a satellite dish, a scanner, a touch screen and / or touchpad, a voice recognition system for receiving voice input, a gesture recognition system for receiving gesture input, etc. These and other input devices are typically connected to the processor circuit 702 through a serial port interface 742 coupled to the bus 706, but may be connected by other interfaces, such as a parallel port, a game port, or a universal serial bus (USB).

[0114] Display screen 744 is also connected to bus 706 via an interface such as video adapter 746. Display screen 744 may be external to computing device 700 or incorporated into computing device 700. Display screen 744 may display information, as well as serve as a user interface for receiving user commands and / or other information (e.g., by touch, finger gestures, a virtual keyboard, etc.). In addition to display screen 744, computing device 700 may include other peripheral output devices (not shown), such as speakers and printers.

[0115] The computing device 700 is connected to a network 748 (e.g., the Internet) through an adapter or network interface 750, a modem 752, or other means for establishing communications over the network. The modem 752, which may be internal or external, may be connected to the bus 706 via the serial port interface 742, such as Figure 7 As shown, or another interface type including a parallel interface may be used to connect to bus 706.

[0116] As used herein, the terms "computer program medium", "computer readable medium" and "computer readable storage medium" are used to refer to physical hardware media, such as a hard disk associated with hard disk drive 714, removable disk 718, removable optical disk 722, other physical hardware media, such as RAM, ROM, flash memory cards, digital video disks, zip disks, MEMs, nanotechnology-based storage devices, and other types of physical / tangible hardware storage media. Such computer readable storage media are distinguished from and do not overlap with communication media (excluding communication media). Communication media embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term "modulated data signal" refers to a signal that sets or changes one or more of its characteristics in a manner that encodes information in the signal. By way of example and not limitation, communication media include wireless media, such as acoustic, RF, infrared and other wireless media, and wired media. Example embodiments also relate to such communication media, which are separate from and do not overlap with embodiments involving computer readable storage media.

[0117] As described above, computer programs and modules (including application programs 732 and other programs 734) can be stored on a hard disk, disk, optical disk, ROM, RAM or other hardware storage medium. Such computer programs can also be received via network interface 750, serial port interface 742 or any other interface type. Such computer programs, when executed or loaded by an application, enable computing device 700 to implement the features of the example embodiments described herein. Therefore, such computer programs represent controllers of computing device 700.

[0118] Example embodiments also relate to computer program products including computer codes or instructions stored on any computer readable medium. Such computer program products include hard drives, optical drives, storage device enclosures, portable memory sticks, memory cards, and other types of physical storage hardware.

[0119] IV. Example Embodiments

[0120] Methods, systems, and computer program products are provided for granular secure user access to private resources. The increased granularity of security policies for user access can reduce security threats to resources. Security policies that indicate user access to secure resources can be based on various combinations of user identity, client-side process (e.g., child process) identity, device identity, device type, device location, resource access type, smart access (e.g., selective traffic routing), etc. For example, a security policy can indicate that user A using computing device B that executes process C with a process signature S (e.g., a signing signature fingerprint, etc.) can access private resource D. The process identity can be indicated by at least one of a process name, a code signing signature, a fingerprint, a process version, or a process publisher. Resource access security policy determination and / or implementation can be performed by a security client and / or a security engine (e.g., a SASE that provides ZTNA).

[0121] In an example, a computing system may include at least one of a client computing device and / or a server providing a security service. The client computing device may be configured to: (a) receive a user identity, (b) execute a process having a process identity, and (c) execute a security client configured to: (i) provide the user identity credentials and the process identity to the server providing a security service, the security service being configured to provide secure access to resources on a private network, or (ii) apply at least one security policy and make an access determination as to whether a combination of the user identity and the process identity authorizes the client computing device to use the resource. The server providing the security service may be configured to: (a) receive the user identity and the process identity, and (b) apply at least one security policy to make an access determination as to whether a combination of the user identity and the process identity authorizes the client computing device to use the resource.

[0122] In an example, the security service may include a secure access service edge (SASE) that provides zero trust network access (ZTNA) to resources in a private network, and the security client may include a ZTNA client.

[0123] In an example, a client computing device may be configured to make an access determination.

[0124] In an example, a server providing security services may be configured to make access determinations.

[0125] In an example, a client computing device is configured to perform an access determination.

[0126] In an example, a server providing security services may be configured to perform access determinations.

[0127] In an example, the process identity may be indicated by at least one of a process name, a process signature, a process version, or a process publisher.

[0128] In an example, a process may include at least one sub-process.

[0129] In an example, the access determination may determine whether the client computing device is authorized to use the resource based on a combination of the user identity and the process identity further combined with at least one of a location of the client computing device or a traffic route of traffic generated by the client computing device.

[0130] In an example, a computer-implemented method may include: determining or receiving, using a client computing device, a user identity of a user; determining or receiving a process identity of a process executed by the client computing device; and determining or receiving an access determination indicating whether a combination of the user identity and the process identity authorizes the client computing device to use a private resource in a private network.

[0131] In an example, the security service may include a secure access service edge (SASE) that provides zero trust network access (ZTNA) to resources in a private network, and the security client may include a ZTNA client.

[0132] In an example, a computer-implemented method may (eg, further) include receiving an indication of at least one security policy indicating whether a combination of the user identity and the process identity authorizes the client computing device to use a private resource, wherein the access determination is based on the at least one security policy.

[0133] In an example, the access determination may be determined by a client computing device.

[0134] In an example, the access determination may be determined by a server providing security services.

[0135] In an example, the access determination may indicate whether the combination of the user identity and the process identity, further combined with at least one of a location of the client computing device or a traffic route of traffic generated by the client computing device, authorizes the client computing device to use the resource.

[0136] In an example, a computer-implemented method may (eg, also) include performing an access determination.

[0137] In an example, a client computing device may perform the access determination.

[0138] In an example, a server with a security service may be configured to perform access determinations.

[0139] In an example, a process may include at least one sub-process.

[0140] In an example, a computer-readable storage medium may have program instructions recorded thereon that, when executed by a processing circuit, perform a method. The method may include, for example: determining or receiving a user identity of a user using a client computing device; determining or receiving a process identity of a process executed by the client computing device; and determining or receiving an access determination indicating whether a combination of the user identity and the process identity authorizes the client computing device to use a private resource in a private network.

[0141] In another example, a computing system includes a client computing device configured to: (a) receive a user identity, (b) execute a process with the process identity, and (c) execute a security client configured to at least one of: (i) provide the user identity credentials and the process identity to a server providing a security service, the security service configured to provide secure access to resources on a private network, or (ii) apply at least one security policy to determine whether a combination of the user identity and the process identity authorizes the client computing device to use the resource.

[0142] In an example, the computing system further includes: a server providing security services is configured to: (a) receive a user identity and a process identity, and (b) apply at least one security policy to make an access determination of whether the combination of the user identity and the process identity authorizes the client computing device to use a resource.

[0143] In an example, the security service includes a secure access service edge (SASE) that provides zero trust network access (ZTNA) to resources in a private network, and the security client includes a ZTNA client.

[0144] In an example, a client computing device is configured to make an access determination.

[0145] In an example, a server providing a security service is configured to make access determinations.

[0146] In an example, a client computing device is configured to perform an access determination.

[0147] In an example, a server providing security services is configured to perform access determinations.

[0148] In an example, the process identity is indicated by at least one of a process name, a process signature, a process version, or a process publisher.

[0149] In an example, the access determination determines whether a combination of the user identity and the process identity, further combined with at least one of a location of the client computing device or a traffic routing of traffic generated by the client computing device, authorizes the client computing device to use the resource.

[0150] In another example, a computer-implemented method includes determining a user identity of a user at a client computing device; determining a process identity of a process executed by the client computing device; and determining an access determination indicating whether a combination of the user identity and the process identity authorizes the client computing device to use a private resource in a private network.

[0151] In an example, the security service includes a secure access service edge (SASE) that provides zero trust network access (ZTNA) to resources in a private network, and the security client includes a ZTNA client.

[0152] In an example, the computer-implemented method further includes receiving an indication of at least one security policy indicating whether a combination of the user identity and the process identity authorizes the client computing device to use the private resource, wherein the access determination is based on the at least one security policy.

[0153] In an example, the access determination is determined by the client computing device.

[0154] In an example, the access determination is determined by a server providing a security service.

[0155] In an example, access determines whether a combination of the user identity and the process identity further combined with at least one of a location of the client computing device or a traffic route of traffic generated by the client computing device authorizes the client computing device to use the resource.

[0156] In an example, the computer-implemented method further includes performing the access determination.

[0157] In an example, a client computing device performs the access determination.

[0158] In yet another example, a computing system includes a server providing a security service configured to: (a) receive a user identity and a process identity of a process executed by a client computing device, and (b) apply at least one security policy to make an access determination whether the combination of the user identity and the process identity authorizes the client computing device to use resources on a private network.

[0159] In an example, the security service includes a secure access service edge (SASE) that provides zero trust network access (ZTNA) to resources in a private network, and the security client in the client computing device includes a ZTNA client.

[0160] In an example, the access determination determines whether a combination of the user identity and the process identity, further combined with at least one of a location of the client computing device or a traffic routing of traffic generated by the client computing device, authorizes the client computing device to use the resource.

[0161] V. Conclusion

[0162] Although various embodiments of the present disclosure have been described above, it should be understood that they are presented by way of example only and not limitation. Those skilled in the relevant art will appreciate that various changes may be made in form and detail without departing from the spirit and scope of the present disclosure as defined in the appended claims. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above exemplary embodiments, but should only be defined in accordance with the appended claims and their equivalents.

Claims

1. A computing system comprising: A client computing device, the client computing device being configured to: (a) receiving the user’s identity, (b) execute a process with a process identity, and (c) executing a security client, wherein the security client is configured to perform at least one of the following: (i) providing the user identity and the process identity to a server providing a security service, wherein the security service is configured to provide secure access to resources on a private network, or (ii) applying at least one security policy to make an access determination whether the combination of the user identity and the process identity authorizes the client computing device to use the resource.

2. The computing system of claim 1 , further comprising: The server providing the security service is configured to: (a) receiving the user identity and the process identity, and (b) applying the at least one security policy to make the access determination whether the combination of the user identity and the process identity authorizes the client computing device to use the resource.

3. The computing system of claim 2, wherein the security service comprises a secure access service edge (SASE) that provides zero trust network access (ZTNA) for the resources in the private network, and the security client comprises a ZTNA client. The computing system of claim 1 , wherein the client computing device is configured to make the access determination.

5. The computing system of claim 2, wherein the server providing the security service is configured to make the access determination. The computing system of claim 1 , wherein the client computing device is configured to perform the access determination.

7. The computing system of claim 2, wherein the server providing the security service is configured to perform the access determination. 8 . The computing system of claim 1 , wherein the process identity is indicated by at least one of a process name, a process signature, a process version, or a process publisher.

9. The computing system of claim 1 , wherein the access determination determines whether a combination of the user identity and the process identity, further combined with at least one of: a location of the client computing device, or a traffic route of traffic generated by the client computing device, authorizes the client computing device to use the resource.

10. A computer-implemented method comprising: determining, at the client computing device, a user identity of the user; determining a process identity of a process executed by the client computing device; as well as An access determination is determined indicating whether a combination of the user identity and the process identity authorizes the client computing device to use a private resource in a private network.

11. The computer-implemented method of claim 10, wherein the security service comprises a secure access service edge (SASE) that provides zero-trust network access (ZTNA) to the resources in the private network, and the security client comprises a ZTNA client.

12. The computer-implemented method of claim 10, further comprising: An indication of at least one security policy is received, the at least one security policy indicating whether the combination of the user identity and the process identity authorizes the client computing device to use the private resource, wherein the access determination is based on the at least one security policy.

13. The computer-implemented method of claim 10, wherein the access determination is determined by the client computing device.

14. The computer-implemented method of claim 10, wherein the access determination is determined by a server providing a security service.

15. A computer-readable storage medium having program instructions recorded thereon, wherein the program instructions, when executed by a processor of a computing device, perform the method according to any one of claims 10 to 14.

Images