Remote server isolation with zero trust architecture

Abstract

The embodiment of the invention relates to remote server isolation using a zero-trust architecture. A zero-trust cloud environment provides access to secure networks and secure network applications. A zero-trust cloud environment performs authentication of a user account and initiates a secure network application, such as an SSH session with a server in a secure network, upon successful completion. The server is instructed to generate an isolated network namespace through which the virtual network interface is bridged to a default network namespace. If network traffic from the virtual network interface is directed to a secure address, the firewall of the default network namespace does not allow the traffic to pass.

Description

Technical Field

[0001] The present disclosure generally relates to providing secure network applications, and more particularly to providing secure network applications utilizing a zero-trust cloud architecture. Background Art

[0002] An organization typically has a network of interconnected computers and servers in one or more physical locations. With the development of networking and the Internet, many organizations have found it beneficial to have employees work remotely, either from their own homes or at client locations, thereby providing a more personalized service to the organization's customers. This development allows employees to access their organization's network over the Internet from locations outside the organization's control.

[0003] Of course, this opportunity also brings serious risks, as the organization has no control over other networks or other individuals (such as attackers) connecting to the same remote network as its employees.

[0004] The Secure Shell (SSH) protocol is an example of a cryptographically secure network protocol that allows network services to be operated over an insecure network. SSH provides a secure channel (e.g., over the Internet) by establishing a client-server relationship between two machines (one is the SSH client and the other is the SSH server).

[0005] For example, one challenge with providing SSH access is that once a user establishes a client connection to a server on a secure network, that user may be able to access other machines on the secure network, perform privilege escalation, move laterally, or otherwise access parts of the network that they are not authorized to access.

[0006] Therefore, it would be advantageous to provide a solution that can overcome the above challenges. Summary of the invention

[0007] The following is a summary of several example embodiments of the present disclosure. This summary is provided to facilitate the reader to provide a basic understanding of such embodiments and does not fully limit the breadth of the present disclosure. This summary is not a broad overview of all contemplated embodiments, is not intended to identify key or critical elements of all embodiments, and is not intended to describe the scope of any or all aspects. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to a more detailed description presented later. For convenience, the term "some embodiments" or "certain embodiments" may be used herein to refer to a single embodiment or multiple embodiments of the present disclosure.

[0008] A system of one or more computers may be configured to perform specific operations or actions by installing software, firmware, hardware, or a combination thereof on the system, which in operation causes the system to perform the actions. One or more computer programs may be configured to perform specific operations or actions by including instructions that, when executed by a data processing device, cause the device to perform the actions.

[0009] In one general aspect, a method may include receiving a request from a client device to authenticate an identity, the identity including at least a unique identifier of a user. The method may also include receiving a request to access a CSNA on a remote server through a zero-trust cloud environment, the remote server being deployed in a secure network environment, the remote server having a default network namespace (DNN), wherein the request includes session credentials for logging into the CSNA, and wherein the secure network environment is communicatively coupled to the zero-trust cloud environment. The method may also include pipelining communications between the client device and the remote server through the zero-trust cloud environment. Other embodiments of this aspect include corresponding computer systems, apparatuses, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0010] Implementations may include one or more of the following features. The method may include configuring a remote server to: generate an isolated network namespace (INN); generate a bridge between the INN and the DNN; assign a name from the INN to a virtual network interface (VNI); and generate a new CSNA in the INN. The method may include: configuring the default network namespace (DNN) firewall of the remote server to discard data packets from the INN that are directed to a secure network environment. The method may include: configuring the DNN firewall to forward data packets from the INN that are not directed to a secure network environment. The method may include: accessing a policy engine to determine a policy that matches: identity, session credentials, and combinations thereof. The method may include: pipelining communications based on the determined policy. The method wherein the CSNA is an SSH session. The method wherein the zero-trust cloud environment includes any of the following: a front-end CSNA server, an access portal server, a back-end server, and any combination thereof. The method wherein the back-end server is configured to connect to a connector deployed in a secure network environment. The method wherein the client device is configured to communicate with the front-end CSNA server. Implementations of the technology may include hardware, methods or processes, or computer tangible media.

[0011] In one general aspect, a non-transitory computer-readable medium may include one or more instructions that, when executed by one or more processors of a device, cause the device to: receive a request from a client device to authenticate an identity, the identity comprising at least a unique identifier of a user. The medium may also receive a request to access a CSNA on a remote server through the zero-trust cloud environment, the remote server being deployed in a secure network environment, the remote server having a default network namespace (DNN), wherein the request includes session credentials for logging into the CSNA, and wherein the secure network environment is communicatively coupled to the zero-trust cloud environment. The medium may also pipe the communication between the client device and the remote server through the zero-trust cloud environment. Other embodiments of this aspect include corresponding computer systems, apparatuses, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0012] In a general aspect, the system may include a processing circuit system. The system may also include a memory containing instructions that, when executed by the processing circuit, configure the system to: receive a request from a client device to authenticate an identity, the identity comprising at least a unique identifier of the user. The system may also receive a request to access a CSNA on a remote server through the zero-trust cloud environment, the remote server being deployed in a secure network environment, the remote server having a default network namespace (DNN), wherein the request includes session credentials for logging into the CSNA, and wherein the secure network environment is communicatively coupled to the zero-trust cloud environment. In addition, the system may also pipe the communication between the client device and the remote server through the zero-trust cloud environment. Other embodiments of this aspect include corresponding computer systems, apparatuses, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0013] The implementation may include one or more of the following features. The memory in the system contains additional instructions, which, when executed by the processing circuit system, also configure the system to: configure the remote server to: generate an isolated network namespace (INN); generate a bridge between the INN and the DNN; assign names from the INN to virtual network interfaces (VNIs); and generate new CSNAs in the INN. The memory in the system contains additional instructions, which, when executed by the processing circuit system, also configure the system to: configure the default network namespace (DNN) firewall of the remote server to discard data packets from the INN that are directed to a secure network environment. The memory in the system contains additional instructions, which, when executed by the processing circuit system, also configure the system to: configure the DNN firewall to forward data packets from the INN that are not directed to a secure network environment. The memory in the system contains additional instructions, which, when executed by the processing circuit system, also configure the system to: access the policy engine to determine the policy that matches the following: identity, session credentials, and combinations thereof. The memory in the system contains additional instructions that, when executed by the processing circuit system, further configure the system to: pipe the communication based on the determined policy. The system wherein the CSNA is an SSH session. The system wherein the zero-trust cloud environment includes any of the following: a front-end CSNA server, an access portal server, a back-end server, and any combination thereof. The system wherein the back-end server is configured to connect to a connector deployed in a secure network environment. The system wherein the client device is configured to communicate with the front-end CSNA server. Implementations of the technology may include hardware, methods or processes, or computer tangible media. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The subject matter disclosed herein is particularly pointed out and distinctly claimed in the claims appended hereto. The above and other objects, features and advantages of the disclosed embodiments will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0015] Figure 1 is an example of a network diagram of a zero-trust network architecture for providing encrypted and secure application services according to an embodiment.

[0016] Figure 2 It is a schematic diagram example of an SSH server providing an isolated environment according to an embodiment.

[0017] Figure 3 is a flow chart of a method for initiating an encrypted secure network session using a zero-trust cloud environment according to an embodiment.

[0018] Figure 4 is a flowchart example of a method for initiating an isolated encrypted secure network session according to an embodiment.

[0019] Figure 5 is an example schematic diagram of a front-end SSH server implemented according to an embodiment. DETAILED DESCRIPTION

[0020] It is important to note that the embodiments disclosed herein are merely examples of many advantageous uses of the innovative teachings herein. In general, statements in the specification of the present application do not necessarily limit any of the various embodiments claimed. In addition, some statements may apply to some inventive features but not to other features. In general, unless otherwise stated, singular elements may be plural and vice versa without loss of generality. In the accompanying drawings, like numbers represent like parts through several views.

[0021] Various embodiments disclosed include a method and system for providing encrypted secure network sessions to a server over a zero trust network. In one embodiment, it is advantageous to additionally isolate the server so that access is only provided to the server and, for the session, access from the server to other parts of the network is not possible.

[0022] For example, in one embodiment, the server provides secure shell (SSH) communication to access the server. It is advantageous to be able to access the server via SSH within a secure network where the SSH server is deployed. According to one embodiment, the SSH server is configured to access other resources, such as servers, devices, applications, virtual machines, software containers, serverless functions, combinations thereof, etc. In one embodiment, it is desirable to provide access only to the SSH server through a zero-trust network, such that once a server is accessed through the zero-trust network, it is impossible to access other elements of the secure network through the SSH server.

[0023] In one embodiment, this provides an additional layer of network security while allowing different access when the SSH server is accessed from within a secure network.

[0024] Figure 1 is an example of a network diagram of a zero-trust network architecture 100 for providing encrypted secure application services according to one embodiment. The present disclosure is primarily directed to providing SSH services in a zero-trust network architecture as an example of an encrypted network protocol for providing network services. It is understood that other protocols can utilize the teachings herein to provide secure network services in a similar manner.

[0025] The client device 110 is operable to communicate with an access portal server 122 and a front-end SSH server 124 implemented in the first cloud environment 120 via a network (not shown). The client device 110 may be a personal computer, a smart phone, a tablet, etc. The client device 110 may include an SSH client application.

[0026] The first cloud environment is a computing environment for providing services using a zero-trust architecture. The first cloud environment can be implemented on one or more cloud infrastructure technologies, such as Azure, Cloud Platform (GCP), Web Services (AWS), etc. For example, the elements of the first cloud environment 120 can be implemented as virtual workloads, such as containers and virtual machines. In some embodiments, the access portal server 122 and the front-end SSH server 124 can be implemented as a single workload. The implementation of the front-end SSH server 124 will be described below. Figure 5 Discuss in more detail.

[0027] The client device 110 sends a request for authentication to the access portal 122. In one embodiment, the access portal server 122 may utilize an identity access management (IAM) service (e.g., from an IAM server 140) to verify the user account requesting access via the client device 110. In one embodiment, the IAM server 140 may be implemented in the first cloud environment 120. The client device 110 may provide login credentials, such as a user name and password, to the access portal server 122 (or IAM server 140). For example, an IAM service may be provided by a server such as And other solutions provided.

[0028] After verifying the identity of the user account, the access portal server 122 can provide instructions that the user account is verified to the front-end SSH server 124. Such instructions can be, for example, sending a token to the client device 110 to encrypt future communications and indicating to the front-end SSH server 124 that the token is a valid token.

[0029] Once the user account is verified, the user device 110 can send a request to the front-end SSH server 124 to initiate an SSH session with a remote server. In one embodiment, the access portal server 122 can provide a graphical user interface (GUI), through which the user of the user device can provide a request to access the SSH session. In some embodiments, the user can select an SSH session to a server among multiple servers. The SSH server is deployed in a secure network environment 130. For example, a first SSH server 134 and a second SSH server 136 (collectively referred to as SSH servers) are deployed in a secure network environment 130. The SSH server is connected to the back-end server 126 through a connector (such as connector 132), and the SSH server communicates with the front-end SSH server 124 through the back-end server 126. The connector is deployed in a secure network environment and communicates with the back-end server 126 of the zero-trust cloud environment 120 to send and receive network traffic. In one embodiment, one or more back-end servers can each communicate with one or more connectors, each of which is deployed in a secure network environment.

[0030] In one embodiment, the backend server 126 may be deployed in the communication between the frontend SSH server 124 and the connector 132. The backend server 126 may communicate with the connector 132, which is implemented in the secure network environment 130.

[0031] Once the SSH channel is established, there is a risk of lateral movement, privilege escalation, or other possible network-based attacks in the secure network environment 130. One object of the present disclosure is to provide isolated SSH sessions so that user accounts cannot access resources in the secure network environment 130 unless they are explicitly allowed in the policy defined by the policy engine 128.

[0032] Figure 2 is an example of a schematic diagram of an SSH server 200 providing an isolation environment implemented according to an embodiment. Figure 1 The first SSH server 134, the second SSH server 136, or both can be configured by the zero-trust cloud platform as Figure 2 SSH server 200 in. SSH server 200 includes a default network namespace 210, in which SSH server 200 is assigned a unique name (e.g., IP address). SSH server 200 is deployed in a secure network environment, such as Figure 1 The secure network environment 130. Additional workloads (such as physical machines, virtual machines, containers, serverless functions, etc.) can also be deployed in the secure network environment and can be accessible to the SSH server 200 through the default namespace 210.

[0033] The front-end SSH server communicatively coupled to the SSH server 200 initiates an SSH session by logging into the SSH server 200 using root (or administrator, superuser, etc.) privileges. The front-end SSH server then configures the SSH server 200 to generate an isolated network namespace 230, which includes network interfaces that do not appear in the default network namespace 210. For example, the default network namespace 210 may include network interfaces assigned with IP addresses 192.168.0.0 to 192.168.0.63, while the isolated network namespace 230 includes virtual network interfaces assigned with IP addresses 10.0.0.0 to 10.0.0.127. According to one embodiment, the size of each namespace (i.e., the number of unique names therein) may be different between the default network namespace 210 and the isolated network namespace 230. The front-end SSH server configures the SSH server 200 to generate a virtual network interface for the isolated network namespace 230.

[0034] The front-end SSH server also configures the SSH server 200 to generate a bridge 220 that connects the network interface of the default network namespace 210 to the virtual network interface of the isolated network namespace 230. The default network namespace also includes a firewall 240 unique to the default network namespace, such as iptables or Filtering Platform (WFP). The DNN firewall 240 allows configuration of IP packet filtering rules, which can be stored as a table, such as a rule table 250. The rule table 250 includes a plurality of rules, each rule being represented by a row in the rule table 250. In one embodiment, each row includes a source 252, a destination 254, and an action 256. Thus, a rule can be configured to allow (i.e., forward) IP packets with a network address translator (NAT) address to pass, while another rule is used to discard packets with IP addresses directed to the default network namespace 210. In some embodiments, a rule can be generated to allow any IP packet that is not directed to the default network to pass.

[0035] With this configuration, a user logging into a shell deployed in the implemented isolated network namespace cannot access addresses outside the isolated environment, but still has full access to SSH server 200 .

[0036] Figure 3 is a flowchart 300 of a method for initiating an encrypted secure network session utilizing a zero-trust cloud environment, implemented according to an embodiment.

[0037] At S310, a request is received to authenticate an identity. The identity may be a user account, and the request originates from a user device. In one embodiment, an identity authentication service may be used, such as supplied by an identity and access management (IAM) server. The user account identity may include a user name, email, password, and similar identifiers. In one embodiment, if the identity is not authenticated (e.g., user name does not exist, wrong password, etc.), the client device may be provided with an error notification indicating that the authentication is unsuccessful. In one embodiment, identity authentication is performed between the client device and the access portal server.

[0038] In one embodiment, authenticating an identity may also include querying a policy engine to determine the security policy applied to a user account associated with the identity. The policy engine includes rules, which, in one embodiment, may be represented as text indicating what a user account is authorized to do, what a user account is not authorized to do, which workloads a user account is allowed to access, which workloads a user account is not allowed to access, or any combination thereof. Policies in the policy engine may also be used to determine the length of time a user account may access certain resources (i.e., workloads).

[0039] At S320, a request to initiate an encrypted secure network application is received. In this example, the network session is an SSH session, where the client device is an SSH client. The request may include an identifier to specify a specific SSH server. The SSH server is in a secure network environment that the client device is attempting to access.

[0040] In an embodiment, the access portal server may generate a GUI through which the client device may instruct the access portal on which SSH server the client device wishes to initiate an SSH session. For example, the access portal server GUI may include a first icon representing a first SSH server, a second icon representing a second SSH server, etc. By clicking on the first icon or the second icon, an instruction is generated to initiate an SSH session with the first SSH server or the second SSH server, respectively.

[0041] In some embodiments, session credentials may be required in order to initiate an encrypted secure network session. The session credentials may be unique to a secure network or a workload of the secure network (e.g., an SSH server). For example, an email address and a corresponding password may be used to authenticate a user at S310, and a username and a corresponding password may be used to log into a requested SSH session at S320.

[0042] At S330, an isolated encrypted secure network session is initiated. For example, a front-end SSH server that is communicatively coupled to an access portal server receives a request from the access portal to initiate an SSH session for a client device. In some embodiments, the front-end SSH server may receive session credentials from the access portal server. Before initiating an SSH session for a client device, the front-end SSH server may verify the session credentials with the SSH server using the received session credentials. Initiating an encrypted secure network session is described below with respect to Figure 4 are discussed in more detail.

[0043] At S340, the encrypted secure network session is piped between the client device and the SSH server. In one embodiment, the session pipelining is performed by the front-end SSH server. The front-end SSH server configures an isolated session, which can be generated based on a policy received from a policy engine, for example.

[0044] Figure 4 is an example of a flowchart 400 of a method for initiating an isolated encrypted secure network session according to an embodiment. Figure 3 An example SSH session.

[0045] At S410, the root credentials are used to log into the SSH server. In one embodiment, the front-end SSH server can use the root (or administrator) user to log into the SSH server in a secure network environment. The root user has the highest level of authorization to operate on the machine, allowing the front-end SSH server to configure the SSH server, for example, to generate an isolated network namespace.

[0046] At S420, the zero-trust cloud environment configures an isolated network namespace within the SSH server. The SSH server is deployed in a secure network environment with a default network namespace. The network namespace may include, for example, a network interface assigned an IP address, which is used by various workloads and components connected to the secure network to communicate with each other. An isolated network namespace is a namespace that does not share any name with the default network namespace. The isolated network namespace may also include a virtual network interface (VNI). Names from the isolated network namespace are assigned to the VNI. In one embodiment, an IP address is assigned to the VNI. By assigning the VNI to an IP address, the VNI can be accessed through a bridge. In one embodiment, if the default setting for a new VNI is closed, the VNI may be turned on. Turning on the VNI may include enabling an interface, thereby allowing it to receive and send IP packets. For example, a front-end SSH server may perform an SSH connection using root credentials and preconfigure an SSH server for a user SSH session.

[0047] At S430, the zero-trust cloud environment configures a bridge in the SSH server to connect the default network namespace to the isolated network namespace. The bridge routes IP packets between the VNI of the isolated network namespace and the network interface of the default network namespace to allow traffic flow in both directions. Configuring the SSH server to generate a bridge can be performed by a front-end SSH server, which uses a root user to instruct the SSH server to generate a bridge, for example, by providing instructions via a secure shell.

[0048] At S440, the session credentials are provided to the SSH server. The session credentials may be captured by the front-end SSH server, the access portal server, or both. The session credentials are used to log into a new application in the isolated network namespace. Thus, a user utilizing the session credentials is ultimately directed to an SSH session via a command line application that is isolated from the rest of the secure network. Traffic to the default network is dropped, while other traffic is forwarded, such as to NAT, as usual. The SSH front-end server pipes the session between the client device and the SSH server, thereby allowing an additional layer of control.

[0049] At S450, the SSH server is instructed to generate a new application associated with the isolated network namespace in response to receiving a request from the zero-trust cloud environment. In one embodiment, the new application is a command line application deployed on the SSH server. The SSH server can be configured to generate the new application using a root user through a front-end SSH server of the zero-trust cloud environment. In one embodiment, IP-based routing rules can be generated in the default network namespace firewall, which indicate how to route IP packets received and sent by components assigned names from the isolated network namespace. For example, iptables can have rules generated based on policies extracted from a policy engine by the front-end SSH server. The new application can be a user SSH session.

[0050] At S460, the zero-trust cloud environment initiates an SSH session between the client device and the SSH server. In one embodiment, the SSH session is piped between the client device and the SSH server by the front-end SSH server. The front-end SSH server configures an isolated session, which can be generated, for example, based on a policy received from a policy engine.

[0051] In an embodiment, a user can log out of an SSH session after a predetermined period of time. In another embodiment, a user can log out of an SSH session. When logging out of an SSH session, the isolated application (SSH terminal) is closed, but the isolated namespace, bridge, and routing rules remain in place. Therefore, the next time the user logs in using the same SSH server and credentials, the infrastructure is already in place to initiate an isolated SSH session.

[0052] Figure 5 1 is an example schematic diagram of a front-end SSH server 124 implemented according to an embodiment. The front-end SSH server 124 includes a processing circuit system 510 coupled to a memory 520, a storage device 530, and a network interface 540. In an embodiment, the components of the front-end SSH server 124 may be communicatively connected via a bus 550.

[0053] The processing circuit system 510 may be implemented as one or more hardware logic components and circuits. For example, but not limited to, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), general purpose microprocessors, microcontrollers, digital signal processors (DSPs), etc., or any other hardware logic components that can perform computations or other information operations.

[0054] The memory 520 may be volatile (eg, random access memory, etc.), non-volatile (eg, read-only memory, flash memory, etc.), or a combination thereof.

[0055] In one configuration, software for implementing one or more embodiments disclosed herein may be stored in memory 530. In another configuration, memory 520 is configured to store such software. Software should be broadly interpreted as any type of instruction, whether referred to as software, firmware, middleware, microcode, hardware description language, or other. Instructions may include code (e.g., source code format, binary code format, executable code format, or any other suitable code format). Instructions, when executed by processing circuit system 510, cause processing circuit system 510 to perform various processes described herein.

[0056] Storage 530 may be magnetic storage, optical storage, solid-state storage, etc., and may be implemented as, for example, flash memory or other memory technology, or any other medium that may be used to store the desired information.

[0057] The network interface 540 allows the front-end SSH server 124 to communicate with, for example, the client device 110, the access portal server 122, the policy engine 128, the SSH server 200, the connector 123, or any combination thereof.

[0058] It should be understood that the embodiments described herein are not limited to Figure 5 Specific architectures are shown, and other architectures may likewise be used without departing from the scope of the disclosed embodiments.

[0059] Various embodiments disclosed herein can be implemented as hardware, firmware, software or any combination thereof. In addition, the software is preferably implemented as an application program, which is tangibly embodied in a program storage unit or a computer-readable medium including a plurality of parts, or a combination of certain devices and / or devices. The application program can be uploaded to a machine including any suitable architecture and executed by the machine. Preferably, the machine is implemented on a computer platform with hardware such as one or more central processing units ("CPU"), memory and input / output interface. The computer platform may also include an operating system and microinstruction codes. The various processes and functions described herein may be a part of the microinstruction code or a part of the application program, or any combination thereof, which may be executed by the CPU, regardless of whether such a computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform, such as an additional data storage unit and a printing unit. In addition, a non-transient computer-readable medium is any computer-readable medium other than a transient propagation signal.

[0060] All examples and conditional language described herein are intended for teaching purposes to help readers understand the principles of the disclosed embodiments and the concepts contributed by the inventors to promote technological progress, and should be interpreted as not being limited to these specifically described examples and conditions. In addition, all statements described herein, including the principles, aspects, and embodiments of the disclosed embodiments and their specific examples, are intended to cover their structural and functional equivalents. In addition, such equivalents are intended to include currently known equivalents as well as equivalents developed in the future, that is, any element developed to perform the same function regardless of the structure.

[0061] It should be understood that any reference to an element using names such as "first", "second" etc. herein does not generally limit the quantity or order of these elements. Rather, these names are generally used as a convenient method to distinguish two or more elements or instances of elements herein. Therefore, reference to the first and second elements does not mean that only two elements can be adopted here, nor does it mean that the first element must be located before the second element in some way. In addition, unless otherwise stated, an element set includes one or more elements.

[0062] As used herein, the phrase "at least one" followed by a list of items means that any of the listed items may be utilized alone, or any combination of two or more of the listed items may be utilized. For example, if a system is described as including "at least one of A, B, and C," the system may include A alone; B alone; C alone; 2A; 2B; 2C; 3A; a combination of A and B; a combination of B and C; a combination of A and C; a combination of A, B, and C; a combination of 2A and C; a combination of A, 3B, and 2C; and so on.

Claims

1. A method for isolating a cryptographically secure network application (CSNA) using a zero-trust cloud environment, comprising: receiving, from a client device, a request to authenticate an identity, the identity comprising at least a unique identifier of a user; receiving a request to access a CSNA on a remote server through the zero-trust cloud environment, the remote server being deployed in a secure network environment, the remote server having a default network namespace DNN, wherein the request includes session credentials for logging into the CSNA, and wherein the secure network environment is communicatively coupled with the zero-trust cloud environment; as well as Communications between the client device and the remote server are piped through the zero-trust cloud environment.

2. The method according to claim 1, further comprising: The remote server is configured to: generate an isolated network namespace INN; generate a bridge between the INN and the DNN; Assigning a name from the INN to a virtual network interface VNI; and creating a new CSNA in the INN.

3. The method according to claim 2, further comprising: The default network namespace DNN firewall of the remote server is configured to discard data packets from the INN directed to the secure network environment.

4. The method according to claim 3, further comprising: The DNN firewall is configured to forward data packets from the INN that are not directed to the secure network environment.

5. The method according to claim 1, further comprising: A policy engine is accessed to determine a policy that matches the identity, the session credentials, and a combination thereof.

6. The method according to claim 5, further comprising: The communication is pipelined based on the determined policy.

7. The method of claim 1, wherein the CSNA is an SSH session.

8. The method of claim 1, wherein the zero-trust cloud environment comprises any one of the following: a front-end CSNA server, an access portal server, a back-end server, and any combination thereof.

9. The method of claim 8, wherein the backend server is configured to connect to a connector deployed in the secure network environment.

10. The method of claim 8, wherein the client device is configured to communicate with the front-end CSNA server.

11. A non-transitory computer-readable medium storing a set of instructions for isolating a cryptographically secure network application (CSNA) using a zero-trust cloud environment, the set of instructions comprising: One or more instructions that, when executed by one or more processors of a device, cause the device to: receiving, from a client device, a request to authenticate an identity, the identity comprising at least a unique identifier of a user; receiving, by the zero-trust cloud environment, a request to access a CSNA on a remote server, the remote server being deployed in a secure network environment, the remote server having a default network namespace DNN, wherein the request includes session credentials for logging into the CSNA, and wherein the secure network environment is communicatively coupled with the zero-trust cloud environment; as well as Communications between the client device and the remote server are piped through the zero-trust cloud environment.

12. A system for isolating encrypted secure network applications (CSNA) using a zero-trust cloud environment, comprising: Processing circuit system; as well as a memory comprising instructions that, when executed by the processing circuitry, configure the system to: receiving, from a client device, a request to authenticate an identity, the identity comprising at least a unique identifier of a user; receiving a request to access a CSNA on a remote server through the zero-trust cloud environment, the remote server being deployed in a secure network environment, the remote server having a default network namespace DNN, wherein the request includes session credentials for logging into the CSNA, and wherein the secure network environment is communicatively coupled with the zero-trust cloud environment; as well as Communications between the client device and the remote server are piped through the zero-trust cloud environment.

13. The system of claim 12, wherein the memory contains further instructions which, when executed by the processing circuitry, further configure the system to: The remote server is configured to: generate an isolated network namespace INN; generate a bridge between the INN and the DNN; assign names from the INN to virtual network interfaces VNI; and generate a new CSNA in the INN.

14. The system of claim 13, wherein the memory contains further instructions which, when executed by the processing circuitry, further configure the system to: The default network namespace DNN firewall of the remote server is configured to discard data packets from the INN directed to the secure network environment.

15. The system of claim 14, wherein the memory contains further instructions which, when executed by the processing circuitry, further configure the system to: The DNN firewall is configured to forward data packets from the INN that are not directed to the secure network environment.

16. The system of claim 12, wherein the memory contains further instructions that, when executed by the processing circuitry, further configure the system to: A policy engine is accessed to determine a policy that matches the identity, the session credentials, and a combination thereof.

17. A system according to claim 16, wherein the memory contains further instructions which, when executed by the processing circuitry, further configure the system to: The communications are pipelined based on the determined policy.

18. The system of claim 12, wherein the CSNA is an SSH session.

19. The system of claim 12, wherein the zero-trust cloud environment comprises any one of the following: a front-end CSNA server, an access portal server, a back-end server, and any combination thereof.

20. The system of claim 19, wherein the backend server is configured to connect to a connector deployed in the secure network environment.

21. The system of claim 19, wherein the client device is configured to communicate with the front-end CSNA server.

Images