[go: up one dir, main page]

WO2016003885A1 - Passerelle de texte en clair pour des communications d'entreprise sécurisées - Google Patents

Passerelle de texte en clair pour des communications d'entreprise sécurisées Download PDF

Info

Publication number
WO2016003885A1
WO2016003885A1 PCT/US2015/038283 US2015038283W WO2016003885A1 WO 2016003885 A1 WO2016003885 A1 WO 2016003885A1 US 2015038283 W US2015038283 W US 2015038283W WO 2016003885 A1 WO2016003885 A1 WO 2016003885A1
Authority
WO
WIPO (PCT)
Prior art keywords
cleartext
endpoint
gateway
secured
computing system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2015/038283
Other languages
English (en)
Inventor
Robert A. Johnson
Sarah K. Inforzato
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Unisys Corp
Original Assignee
Unisys Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Unisys Corp filed Critical Unisys Corp
Priority claimed from US14/753,437 external-priority patent/US20150381567A1/en
Publication of WO2016003885A1 publication Critical patent/WO2016003885A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks

Definitions

  • the present disclosure relates generally to security arrangements for cloud computing.
  • the present disclosure relates to a cleartext gateway for secure enterprise communications.
  • Modern organizations generate store, and communicate large quantities of data.
  • organizations include individuals haying different rights to data, or different rights to communicate with other individuals or access particular computing resources. It is frequently important that such organizations be able to quickly and securely access the data stored at the data storage system.
  • data stored at a data storage system, or communicated between computing systems be recoverable if the data is communicated or written incorrectly or are otherwise intercepted or corrupted.
  • Unisys Corporation of Blue Bell, Pennsylvania developed a Stealth solution that uses a kernel-level driver to implement end-to-end cryptographic connections for communication of data across public and private networks.
  • This solution allows users to communicate with other users having common user rights, while segregating user groups by way of assignment of different cryptographic keys used for each user group, or "community of interest".
  • the Stealth solution has some drawbacks. For example, such solutions lack capabilities to allow connection by remote devices to a network, and to allow connection of devices that are incapable of implementing particular security features that are used by the Stealth solution.
  • IPsec internet Protocol Security
  • IPsec is an end-to- end security scheme of the Internet Protocol Suite.
  • IPsec operates in the Internet Layer rather than operating in the upper layers of the TCP/IP model.
  • IPsec protects any application traffic across an Internet Protocol (IP) network.
  • Applications do not need to be specifically designed to use IPsec, whereas TLS/SSL is required to be designed into an application to protect the application protocols, in addition, IPsec operates in both IPv4 and iPv6-enahled networks.
  • IPsec-enabled systems typically negotiate to create IPsec tunnels, or secure tunnels, on a point-to-point basis, rather than allowing for data access by multiple entities within the same "community of interest".
  • IPsec is only available on some modern computing systems, and may be limited in availability in different types of systems, such as mobile devices, or in cloud environments.
  • different implementations of IPsec on different types of computing systems are handled differently, leading to inconsistencies in connection parameters.
  • IPsec is built based on a premise that two computing systems can negotiate security parameters; when two such systems intend to form a secure tunnel, that tunnel is established through use of an IKE key exchange, which requires a response to an initial transmission.
  • IKE key exchange which requires a response to an initial transmission.
  • trading of security parameters may not be possible.
  • the present disclosure relates generally to security arrangements for cloud computing.
  • the present disclosure relates to a cleartext gateway for secure enterprise communications.
  • a gateway computing system includes a memory storing cleartext gateway software and a programmable circuit communicatively connected to the memory.
  • the programmable circuit is configured to execute computer-executable instructions including the cleartext gateway software. Execution of the cleartext gateway software by the programmable circuit causes the gateway computing system to instantiate at the gateway computing system a virtual device router including a cleartext interface configured to send and receive data packets from a cleartext endpomt and a secured interface configured to exchange data packets with one or more secured endpoints within a secured enterprise network, and load the virtual device router with community of interest material from an authentication server, the community of interest material associated with one or more communities of interest configured to allow access to the cleartext endpomt.
  • a method of routing traffic between a cleartext endpoint and a secured enterprise network includes instantiating at a gateway computing system a virtual device router associated with the cleartext endpoint; the virtual device router including a cleartext interface configured to send and receive data packets from a cleartext endpoint and a secured interface configured to exchange data packets with one or more secured endpoints within a secured enterprise network.
  • the method further includes loading the virtual device router with community of interest material from an authentication server, the community of interest material associated with one or more communities of interest configured to allow access to the cleartext endpoint.
  • a secured enterprise network allowing connection to a cleartext endpoint.
  • the secured enterprise network includes a plurality of secured endpoints configured to exchange secured communications among endpoints sharing a common community of interest, and a gateway computing system communicatively connected to the plurality of secured endpoints.
  • the gateway computing system includes a virtual device router including a cleartext interface configured to send and receive data packets from a cleartext endpoint and a secured interface configured to exchange data packets with one or more secured endpoints within a secured enterprise network.
  • the virtual device router includes community of interest material from an authentication server, the community of interest material associated with one or more communities of interest configured to allow access to the cleartext endpoint.
  • Fig. I illustrates an example architecture in which aspects of the present disclosure can be implemented
  • FIG. 2 illustrates an example architecture including a cleartext gateway computing device in the context of a secure enterprise network
  • Fig. 3 illustrates an example virtual data relay instantiable within a cleartext gateway computing device to establish a cleartext connection to an endpoint not resident within the secure enterprise network;
  • FIG. 4 is a flowchart of a method for instantiating virtual data relays in a cleartext gateway computing device, according to an example embodiment of the present disclosure
  • FIG. 5 is a flowchart of a method for configuring networking settings for a virtual data relay within a gateway computing device, according to an example embodiment
  • FIG. 6 is a flowchart of a method for communicating with an external endpoint from a secure enterprise network, according to an example embodiment
  • Fig. 7 is a messaging flow diagram of a license VDR of a cleartext gateway computing device at an authentication service, according to an example embodiment
  • FIG. 8 is a messaging flow diagram of a VDR of a cleartext gateway computing device at an authentication service and licensing service, according to an example embodiment
  • Fig. 9 is a messaging flow diagram of a VDR of a cleartext gateway computing device having existing licenses at an authentication service, according to an example embodiment
  • Fig. 10 is a messaging flow diagram of a VDRs managed at a cleartext gateway computing device with an authentication service, according to an example embodiment
  • Fig. 1 1 illustrates a state diagram showing connectivity states of a cleartext gateway computing device, in an example embodiment
  • Fig. 12 illustrates a network topology incorporating a cleartext gateway device and allowing communication between cleartext endpoints and endpoints included in a secured enterprise network, according to an example embodiment
  • FIG. 13 illustrates an example computing system in which aspects of the present disclosure can be implemented
  • Fig. 14 illustrates an example virtualization environment implemented on a computing system, illustrating a mechanism by which private-domain and cloud-based virtual machines can be implemented.
  • Fig. 15 illustrates an example multi-user computing arrangement illustrating shared computing resources across different partitions and/or virtual machines, according to example embodiments.
  • embodiments of the present invention are directed to methods and systems for providing a cleartext gateway system allowing cleartext access between computing systems wishing to connect to a secured enterprise, for example from a secure cloud-based system or a remote, secured, and trusted computing system that does not require a separate secured connection (e.g., VPN) as an additional layer of communication security to the overall system.
  • a separate secured connection e.g., VPN
  • Such arrangements as discussed herein provide flexibility to allow trusted devices external to a secured enterprise to connect to portions of the enterprise that trust those endpoints.
  • endpoints such devices that are not part of the enterprise are referred to herein as "cleartext endpoints" since they refer to endpoints that connect to a gateway to access internal resources of a secured enterprise network, but do not require a separate securing of the connection between those devices and the gateway, for example by VPN. Accordingly, the methods and systems of the present disclosure provide uniform security across public and private domain portions of an organization's network, simplifying administration of an overall network and improving flexibility regarding data storage, license allocation, and computing resource allocation. [0041] According to example embodiments discussed herein, endpoints can include computing systems and virtual machines in a secured enterprise network that may be isolated by encrypting transmissions between those systems with keys possessed only by an intended recipient.
  • the virtual machines may be logically organized into a number of comtnunity-of-interest (COl) groups.
  • COl comtnunity-of-interest
  • Each COl may use an encryption key to secure communications within the COl, such that only other endpoints in the COl may decrypt the message.
  • Endpoints may be automatically provisioned with configuration information, such as the encryption keys, when the endpoint joins the secured network, e.g., when a virtual machine is started.
  • the provisioning information may be created based on a template stored on a configuration server.
  • COl groups and associated authentication, allows for complete opacity of a network for devices not belonging to a COl group, allowing a secured enterprise network to appear to have different computing system endpoints therewithin based on the COl to which that endpoint or device belongs.
  • the cleartext gateway establishes virtual device routers that are dedicated to each endpoint not included in the secured enterprise.
  • Such virtual device routers can be dedicated to specific endpoints, acting as a proxy for that endpoint from the perspective of devices in the secured enterprise network.
  • proxying allows for connection of cleartext endpoints that lack capability natively to connect to a Stealth network to connect to that network via a router component, with individual virtual data relays associated with each such endpoint.
  • the cleartext gateway of the present disclosure allows for direct addressing of such cleartext endpoints via the native IP addressing of those endpoints themselves, via the cleartext gateway (e.g., without requiring addressing to the gateway itself).
  • endpoints such as virtual machines
  • a network may be isolated by encrypting transmissions between the endpoints with keys possessed only by an intended recipient.
  • the endpoints may be logically organized into a number of comraunity-of-interest (CO! groups.
  • COl may use an encryption key to secure communications within the COl, such that only other virtual machines in the COl may decrypt the message.
  • Virtual machines operating as endpoints may be automatically provisioned with configuration information, such as the encryption keys, when the virtual machine is started.
  • the provisioning informatio may be created based on a template stored on a configuration server.
  • the present disclosure relates to a cleartext gateway computing device useable in connection with a secured enterprise network implementing Stealth technology provided by Unisys Corporation of Blue Bell, Pennsylvania.
  • the cleartext gateway allows connection to the secure enterprise network by trusted external endpoints, such as mobile devices or cloud devices implementing specific trusted software with which a separate VPN connection to a gateway may not be required. Rather, the external endpoint itself may manage security by connecting to the gateway via a dedicated connection, or by being located within a trusted network.
  • trusted external endpoints such as mobile devices or cloud devices implementing specific trusted software with which a separate VPN connection to a gateway may not be required. Rather, the external endpoint itself may manage security by connecting to the gateway via a dedicated connection, or by being located within a trusted network.
  • Example arrangements in which a cleartext gateway may be used are illustrated in connection with Figure I, below,
  • the architecture 100 represents a schematic arrangement useable to establish a connection to a computing architecture external to a private domain.
  • the architecture 100 as shown includes computing systems, such as physical and virtual machines, established in both a private domain (e.g., managed within an organization) and in a public domain, for example either as stand-alone computing systems connected to the private domain via the Internet, or a cloud-based domain (e.g., on computing systems that are managed from a public domain or third-party network).
  • a private domain e.g., managed within an organization
  • a public domain for example either as stand-alone computing systems connected to the private domain via the Internet, or a cloud-based domain (e.g., on computing systems that are managed from a public domain or third-party network).
  • the architecture 100 includes an external environment 101, including cloud domain 102, and a private domain 104.
  • the private domain 104 can include both a yirtualized component 106, and an enterprise support component 108.
  • the architecture represents computing resources available to an enterprise for managing, for example, computing or storage tasks.
  • the cloud domain 102 includes a plurality of configurable cloud-based virtual machines 1 10 (shown as virtual machines, or VMs, 1 lOa-b).
  • the cloud-based virtual machines 1 10 can be configured for use in connection with a common virtual network, or vLAN 1 12, that allows the cloud-based VMs 110 to intercommunicate.
  • the vLAN 112 is communicatively connected to the private domain, for example via a gateway device 1 14, as discussed below, for communication with locally- managed virtual machines within the private domain 104.
  • a gateway device 1 14 as discussed below
  • the external environment 101 can include one or more other types of endpoints, e.g., endpoint 140, that are not included within the devices specifically managed within the private domain 104, but intended to be trusted by endpoints within the private domain 104.
  • Such devices can include, for example devices hosting or communicatively connected to a Stealth Secure Virtual Terminal ("SSVT") device, provided by Unisys Corporation of Blue Bell, Pennsylvania. Example operation of such a device is described in a number of applications, including: U.S. Provisional Patent Application No. 61 /389,51 1, filed Oct. 4, 2010, and entitled "System and Method for Providing a USB Stick-Based Thin Client", Attorney Docket No.
  • SSVT Stealth Secure Virtual Terminal
  • a secured, e.g., VPN-based connection is not available, so a cleartext-based connection is used, accordingly to example embodiments of the present disclosure.
  • a cieartext gateway device is provided herein that implements a cieartext interface by which such devices can connect to trusted devices within the private domain 104.
  • a gateway device 1 14 provides a communication location for external endpoints, such as endpoint 140 or cloud-based VMs 1 10, to coordinate communication with private domain systems.
  • the broker 116 included within gateway device 1 14 in the embodiment shown, can be used to establish secure communications with such public domain endpoints, for example by instantiating and managing virtual data relay devices, also known as virtual device routers, or VDRs 1 18, that manage private-domain community of interest keys and filters for such external endpoints while maintaining a dedicated connection to those external endpoints, including endpoint 140 and cloud-based VMs 1 10.
  • VDRs 1 18 can include, for example, a Stealth-based interface that uses private-domain community of interest keys and filters, also referred to herein as VPN COI keys and filters, for communication with private domain VMs, while providing a cieartcxt interface via the gateway device 1 14 to a cloud- based VM 110 for communication over the internet. Details regarding a cleartext implementation of the gateway device 114 and associated broker 1 16 are discussed in further detail below in connection with Figs. 2-3.
  • the gateway device 1 14 and broker 1 16 can be configured to provide cleartext communications to an external endpoint, as well as Steal h- based secure communications with other private domain systems.
  • the broker 1 16 should be configured with appropriate Stealth-based credentials, as well as the service community of interest and filters to be used, as well as details regarding that cloud broker's connection useable to establish the cleartext connection.
  • Other configuration features can be initialized and set prior to addition of external endpoints as noted herein.
  • a credcntialing service 122 can be provided that connects to the gateway device 1 14 and the broker 1 16 via a management vLA 120.
  • the credentialing service 122 can be implemented as a separate virtual machine or service, and generates and provides credentials for use across the external environment 101 including within the cloud domain 102, such that credentials need not be stored at each VM when that VM is created; rather, credentials for VMs can be retrieved on demand, for example based on requests received at the gateway device 1 14.
  • credentials specific to their purpose are provided at boot time, used immediately to authenticate a VM and authorize its COTs, and then the credentials are discarded. Use and discarding of credentials after authentication prevents replay attacks, duplicating VMs, and RAM/VM scraping for credentials.
  • a plurality of private domain yirtual machines 124 can be maintained within the private domain 104. These VMs 124 can be within the same or different COIs to each other and to the cloud-based VMs 1 10 and/or external endpoints 140.
  • a licensing service 126 can be implemented within the private domain 104 as well, to provide management functions associated with the various cloud-based VMs 1 10, 124 or other endpoints (e.g., endpoint 140) created within or managed by the overall arrangement.
  • the licensing service 126 can be implemented on a licensing server, and can provide license issuance, tracking, and logging of license requests within the Stealth network.
  • the enterprise support component 108 can include systems used to provide security to computing systems, including both virtual systems and physical systems, within the enterprise.
  • the enterprise support component 108 can include a plurality of local systems 130 (e.g., hardware or virtual systems) as well as Stealth- enabling systems including an authe tication service 133 and a security appliance 134.
  • the authentication service 133 maintains and distributes community of interest keys in response to receipt of credentials in a request (as have previously been retrieved by a hardware or virtuaiized system from the credentialing service 122).
  • the authentication service 133 can also maintain and distribute filters for use in connection with such community of interest keys for controlling communicative access among systems in the architecture 100.
  • the authentication service 133 corresponds to a Stealth authentication service that can be used to authorize each Stealth-based (secured) endpoint within an enterprise, as well as via cloud-based VMs 1 10, cleartext endpoints such as endpoint 140 connected via the cloud domain 102, and VDRs 1 18 used to communicate with such cloud-based VMs and other devices in the cloud domain 102.
  • cloud-based VMs 1 10, as well as other external endpoints are authenticated and authorized.
  • a first authorization is to authenticate the IPsec VPN connection and authorize the corresponding VDR's COls, providing the VDR 1 1 8 that is associated with each particular VM 1 10 with COI keys and filters.
  • a second authentication is to authenticate a logon service of the VM 1 10, and authorize cloud-based COls for use within the cloud.
  • This second authentication is performed in the case of a cleartext connection to the secure enterprise network as well, despite the first authorization being avoided (with COI keys and filters being obtained by an authorized device having received previously an authentication key and access address information).
  • the logon service can be authenticated using an Active Directory instance or via an authentication performed from the enterprise domain.
  • the authentication service 133 may need to include particular settings to accommodate a cleartext gateway computing device, such as gateway device 114, in some embodiments.
  • the authentication service 133 may be configured to validate individual VDR traffic from VDRs 1 18 at the gateway device 114, or multiple devices 1 14 may be included in a network. Accordingly, an XML file can designate a particular authorization group and can be loaded at respective gateway devices i 14 to associate those devices with a particular authentication service 133.
  • the security appliance 134 can be used as a secured endpoint to which other non- secured computing systems or enterprise resources can be connected (e.g., SAN systems, or other storage).
  • the security appliance 134 could alternatively be used as the licensing service 126.
  • the security appliance 134 can be removed altogether (e.g., in entirely IPsec- based implementations).
  • a cloud- based VM can include an applet 131 that stores service mode credentials 132 useable to initiate authentication of the cloud-based VM 1 10. Additionally, the service mode credentials 132. can be used to obtain service mode keys and/or filters useable to access the authentication service 1 33, and thereby obtain virtual machine keys and filters that associate the VM with a particular community of interest. Similarly, for other types of devices, service mode credentials 132 can be provided to such devices, for example using a hard- coded SSVT device, as noted above. In example embodiments, credentialing of VMs 1 10 or endpoint 140 can be accomplished via the applet 131 .
  • Fig. 1 overall, it is noted that although the present disclosure relates to methods of integrating cloud-based virtual machines and external endpoints into a private virtualization environment, it is noted that in initializing the architecture 100 of Fig. 1 , particular security features should be initialized prior to adding cloud-based VMs, such as VMs 1 10, to such an arrangement. For example, communities of interest, filter sets, and roles are typically created in the authentication service 133 for such external endpoints. Furthermore, one or more security groups corresponding to the roles intended to be assigned to a particular endpoint should be created, for example in Active Directory. User members of a security group should also be defined.
  • the security appliance 134 as well as the licensing service 126 should be initialized and configured to be assigned an internet-routable IP address (or addresses, if multiple such systems are deployed) and particular communities of interest, such as an administrator COI, a service COI, and a license COI should be defined alongside associated filters.
  • an administrative service filter may allow access to any VM within the arrangement, while a license filter that is distributed to a remote system should limit access by that system using the licensing COI to communications with the licensing and logging server, despite the fact that each of the other VMs will also be members of that COI for the licensing/logging requirements associated with those other VMs.
  • a security installation package e.g., to administer Stealth within each VM to be instantiated is prepared for inclusion in each VM, and for each OS hosted within a VM.
  • a gateway device 1 14 provides a cieartext interface that can provide dedicated, cleartext connections to endpoints that are not explicitly included within a private domain 104.
  • endpoints can include, for example, external endpoints 140, which may be mobile devices or other devices that a user may wish to use in connecting to the private domain either from external to the private domain or from within a secure enterprise network.
  • VPN connection is not required (or even possible in the event of connection of the endpoint 140 within a secured enterprise network)
  • a cleartext gateway computing system provides a proxying service by which the cieartext gateway manages routing and visibility of endpoints within the private domain on behalf of the external endpoint.
  • Fig. 2 illustrates an example architecture 200 including a cleartext gateway computing device, such as gateway device 1 14 in the context of a secure enterprise network 202.
  • the cleartext gateway computing device i 14 operates as a layer 3 forwarding device which performs a proxying function between cleartext endpoints 140a-b and secured endpoints 160.
  • the proxying function operates transparently in such a way that the systems in the secure enterprise network communicate with the same IP address as configured on the cleartext endpoint.
  • the packet path between the secured endpoints and the cleartext endpoints must pass through the cleartext gateway computing device 1 14 as a routing hop, bidirectionaliy .
  • the cleartext network is a subnet in which the addresses of the proxied cleartext endpoint systems reside, while the secured network corresponds to one or more subnets in which the secured endpoints 160 reside,
  • the cleartext gateway computing device 1 14 includes a broker 1 16, as well as a plurality of cleartext VDRs 118a-b.
  • the broker 1 16 corresponds to a service useable to manage the cleartext VDRs 1 18a-b, including creation of such VDRs for use wi th cleartext endpoints 140a-b.
  • Each of the cleartext VDRs 118a-b is instantiated such that it is dedicated to an associated cleartext endpoint 140a-b.
  • Such cleartext endpoints include associated COl information I i 9a-b which corresponds to the COIs associated with the users of the cleartext endpoints 140a-b.
  • the COI information 1 19a-b respectively expose only particular secured endpoints 160 (e.g., VMs or physical computing systems) within the secure enterprise network 202.
  • the COI information i l9a-h is retrieved from the authentication service 133 during authentication of the cleartext endpoint to the cleartext gateway computing device 1 14, as noted below in conjunction with Figs. 4-6.
  • the cleartext gateway computing device 1 14 further includes a license VDR 150 which maintains a license connection to licensing service 126.
  • the license VDR 150 maintains this connection to validate the operation of the cleartext gate way computing de vice 1 14; as explained below, upon disconnection of the license VDR 150 from the licensing service 126, the broker 1 16 halts operation of each of the cleartext VDRs 1 18a-b until communication with the licensing service 126 can be reestablished.
  • a routing table 152 is established in the cleartext gateway computing device 1 14, and is used for routing traffic exchange to and from secured endpoints 160 from the cleartext endpoints 140a-b via VDRs 1 18a-b.
  • the routing table 152 maintains network addresses of the cleartext endpoints 140a-b, as well as for secured endpoints 160.
  • the routing table 152 manages IP addresses for each of the VDRs 1 18a-b; in example embodiments, each VDR manages an IP address for an internal, or secured, interface, as well as an external, cleartext interface, as illustrated in Fig. 3.
  • the routing table information can then be used to determine routing of data from the secured endpoints to the cleartext endpoints 140 by ensuring such routing occurs through the cleartext gateway computing device 1 14.
  • the VDRs map traffic received from cleartext endpoints 140 to particular secured endpoints that are members of a common community of interest, based on community of interest information 1 19 associated with the cleartext endpoint by way of the associated VDR 1 18.
  • each VDR 1 18 is assigned a number of attributes for use within the secure enterprise network 202.
  • attributes include, for example, a unique name and network namespace, a virtualized network interface assigned to the cleartext network, a virtualized network interface assigned to the secured enterprise network, a protocol daemon configured to implement Stealth-based protocols, such as MLSTP, a set of communities of interest, an IP address presented to endpoints in the secured enterprise network, an IP address used as routing hop to the cleartext network, and one or more policy routing rules.
  • a control daemon 154 manages the run-time configuration of the network interfaces, the VDRs, IP policy-based routing table 152, and forwarding rales required to map traffic between a cleartext endpoint 140 and secured endpoints 160 for authorized COls. It also provides an administrat ve interface for management of the cleartext gateway computing device 1 14.
  • the administrative interface can be, in some embodiments, a command line interface by which an administrative user can inquire into the status of VDRs 1 18 within the cleartext gateway computing device 1 14 as well as license VDR 150, e.g., by administrative command.
  • An administrative user can also, for example, start, stop, reload, or rollback particular VDR configurations, as well as to snow interfaces for each VDR and the status of such interfaces.
  • control daemon 154 may perform SSH or other authen ication services, may manage system logs using a syslog APT, set firewall rales using packet filters, or can set a Net-SNMP agent to provide read-only access to certain system configuration and/or performance data. Other operations may be available as well, in alternative embodiments.
  • the control daemon 154 includes a plurality of subordinate threads which assist in governing operation of the cleartext gateway computing system 1 14. Such threads can assist by, for example, executing commands from a configuration file at startup, creating VDR data paths via the routing tables 152, or initializing secured packet processing (e.g., using Stealth secured communications technologies, provided by Unisys Corporation of Blue Bell, Pennsylvania) for each VDR by obtaining COI material and niter rules from the authentication service 133 for that VDR.
  • the control daemon 154 can be configured to handle configuration and management commands received via the management interface 156, which provides a terminal or automated arrangement. The control daemon 154 can maintain the license tunnel.
  • the cleartext gateway computing device 1 14 includes a provisioning utility installed thereon that delivers endpoint software useable within a Stealth- enabled network, allowing the gateway device 1 14 to operate within the secured enterprise network, such as specific registry and networking settings to be used.
  • the provisioning utility may also allocate, for the cleartext gateway computing device 1 14 Stealth-based security credentials for VDRs that may be instantiated at the cleartext gateway computing device 1 14,
  • the cleartext gateway computing device 1 14 can be configured to perform one or more logging or management operations via management interface 156.
  • a dump utility could be included to assemble configuration, logs, and other feedback into a single file to be used for system troubleshooting.
  • an enterprise management agent could be used to monitor operational statistics of the cleartext gateway computing device 1 14, for example to provide to a management server within the secure enterprise network.
  • one or more scripts may be included as well, which can be executed during particular events, such as system startup, shutdown, VDR configuration, or other events.
  • the cleartext gateway computing device 1 14 makes data forwarding decisions based on values in the packet, rather than only the destination address.
  • the kernel provides an ordered set of rules containing matching criteria which are evaluated to determine the routing table to employ for the frame.
  • the next hop for a packet can be based on the source address of the frame, and this feature is used by the cleartext gateway computing device 1 14 to relay frames for a given cleartext endpoint 140 through a particular VDR 1 18.
  • the cleartext gateway computing device 1 14 maintains a configuration status in a tree structure in memory, for example a tree structure can be managed that includes various data types, such as strings (useable for naming), IP addresses, route definitions, integers, or other features, and can be used to define specific paths.
  • Example paths managed in a configuration tree structure can include: a configuration version, a hostname of the cleartext gateway computing device 1 14, logging options, authentication methods (e.g., LDAP, NTLM, none, etc.), bindings used to communicate with an authentication server, a list if network interfaces or interface names, text labels for such interfaces, IP addresses assigned to each namespace, virtual interfaces and mappings to physical interfaces, a physical interface definition, virtual LANs managed at the cleartext gateway computing device 1 14, a license VDR, an address of a secure interface, directories in which license VDR provisioning files exist and other settings for a license VDR (e.g., destination addresses), IP address pools and pool ranges, and routing table entries associated with various namespaces.
  • authentication methods e.g., LDAP, NTLM, none, etc.
  • bindings used to communicate with an authentication server e.g., a list if network interfaces or interface names, text labels for such interfaces, IP addresses assigned to each namespace, virtual interfaces
  • Fig. 3 illustrates an example virtual data relay arrangement 300 including VDR 118.
  • the VDR 1 1 8 is instantiabie within a cleartext gateway computing device 1 14 to establish a cleartext connection to an endpoint not resident within the secure enterprise network, such as network 202.
  • a VDR. 1 18 contains COT information 1 19 associated with the cleartext endpoint 140, and also includes virtualized interfaces directed toward the cleartext endpoint 140 and toward a secure enterprise network and associated secured endpoints 160, accordingly.
  • the VDR I i 8 in the embodiment shown, includes a secure interface 302 and a cleartext interface 304.
  • Each of the secure interface 302 and cleartext interface 304 are assigned different ⁇ addresses, to allow the interfaces to operate as rioted above, allowing the broker 1 16 to manage traffic based on the endpoint from which data is received and to be sent to, using routing tables managed in the cleartext gateway computing device 1 14.
  • each cleartext endpoint 140 and associated VDR 1 18 forming a clear text subnet will include an IP address for the cleartext gateway computing device 1 14, as well as additional IP addresses for each cleartext interface 304, and an IP address for internal routing. Accordingly, in an example configuration including ten cleartext endpoints on one subnet that should participate in the secured enterprise network, a cleartext subnet will include twelve IP addresses.
  • a daemon 306 is instantiated as part of the VDR 1 1 8, and controls communication via the secure interface.
  • the daemon 306 is a "Stealth" daemon configured to implement Stealth-based communications, and can process traffic for a dedicated cleartext endpoint via the secure interface 302 from the VDR.
  • the cleartext gateway computing device 1 14 assigns various namespaces for management of data routing among endpoints, including network namespaces, a global namespace, and VDR namespaces.
  • network namespaces the cleartext gateway computing device 1 14 provides the capability to assign separate network namespaces to a process tree.
  • a network namespace is logically another copy of the network stack which contains its own interfaces, route tables, policy rules, and firewall rules.
  • the cleartext gateway computing device 1 14 makes use of multiple network namespaces to route traffic between the secured network and cleartext network.
  • the global namespace represents a default namespace including the secure interface 302, an "intra" interface defining VDR routings, and the cleartext interface 304. Two bridge devices are also allocated and used as a path to the VDR namespaces.
  • VDR namespaces are used to isolate daemons 306 associated with VDRs, which are allocated to process traffic for individual cleartext systems, and for the license VDR 150 (which may also have a corresponding daemon, not shown).
  • VDR namespace Within each VDR namespace is a secured interface, an "intra” interface, and a virtual "tap" adapter created by the control daemon 154.
  • the secured interface is used for Stealth-related packet I/O.
  • Fig. 4 is a flowchart of a method 400 for instantiating virtual data relays in a cleartext gateway computing device, according to an example embodiment of the present disclosure.
  • the method 400 includes instantiating the device (step 402), such as by initializing VDRs 118, for each cleartext endpoint (e.g., cleartext endpoints 140) for which a connection to a secure enterprise network is to be made.
  • Instantiating the VDR can include a variety of operations; for example, in some embodiments, an instantiation operation includes forming a daemon useable and associated with the VDR, and processing configuration parameters associated with the VDR. In such embodiments, a startup configuration can be loaded from a file.
  • IP addresses are assigned to a secure interface and a cleartext interface portion of the VDR (step 404).
  • bridge devices are instantiated, including the secure bridge device and "intra" bridge device included in the VDR and which define the routing to the secure enterprise network and through the VDR between cleartext and secure interfaces, respectively.
  • each bridge device is assigned an IP address.
  • a communication associated with the associated interface can be transmitted from that interface (e.g., an ARP) to update the L2 neighbor cache of systems on the network to which that interface is oriented.
  • Received replies indicate that another system already has the address to be assigned to the interface. Assuming no replies are received, the cleartext interface 304 and secure interface 302 of the associated VDR are assigned IP addresses.
  • a global routing table is created (step 406), and a license tunnel is established (step 408).
  • the license tunnel creation may include, for example, creation of a license VDR, initiation of a secure daemon, and loading of locally- stored COl key material used by the license VDR to establish the license tunnel.
  • the cleartext gateway computing device 114 is authorized to communicate with the authentication service 133. Accordingly, in such embodiments, the cleartext gateway computing device 114 can connect to the authentication service 133 to obtain community of interest information (e.g., COl keys and filters associated with the user of the cleartext endpoint with which the VDR is used). Once the COl information is loaded in the respective VDR (e.g., into a secure daemon associated with the VDR), the cleartext gateway computing device 1 14 can determine whether the license tunnel remains established. The VDR will apply filter rules based on the received COl information, and the VDR will be set to a "pending license" state.
  • community of interest information e.g., COl keys and filters associated with the user of the cleartext endpoint with which the VDR is used.
  • the method 400 accordingly includes loading COl information (e.g., keys and filter rales) associated with each example COl into the corresponding VDR.
  • COl information e.g., keys and filter rales
  • each VDR. will obtain COl keys and filter lists associated with that COl and endpoint, respectively, and apply those at the first and second VDRs. Accordingly, a first cleartext endpoint will access only endpoints within COT A through an associated VDR, while a second cleartext endpoint will access only endpoints within COl B through a different associated VDR.
  • a hook script is stored at the cleartext gateway computing device 114, and is passed some amount of system configuration information via standard input Hooks may provide context-specific configuration information. For example, a hook called during the interface configuration stage may be provided the name of the interface which is being configured. If a hook script exists in the designated path, and is executable, it will be called.
  • Example hook scripts executable by the cleartext gateway computing device 1 14 include a startup hook script, which initiates startup of the cleartext gateway computing device 1 14, a shutdown hook script which terminates operation of the cleartext gateway computing device 1 14, or an interface up hook script, which receives an identification of an interface and enables that interface.
  • Fig. 5 is a flowchart of a method 500 for configuring networking settings for a virtual data relay within a cleartext gateway computing device, according to an example embodiment.
  • the method 500 can be performed, for example, as part of instantiating VDRs for a cleartext gateway computing device 1 14, such as is illustrated as part of method 400 above (e.g., at steps 402-404).
  • the method 500 includes instantiating a VDR for each cleartext endpoint for which communication with a secure enterprise network is desired (step 502). In example embodiments, this can include creating a unique network namespace in the configuration tree of the cleartext gateway computing device 1 14 for the VDR based on a supplied VDR number.
  • each cleartext gateway computing device 1 14 can be mapped to multiple VLA arrangements.
  • each VLAN When defining a namespace, each VLAN will be associated with a "vdrset" namespace that can include one or more VDRs 1 1 8 assigned thereto.
  • the name When naming or associating a VDR 1 18 to a particular namespace, the name can be, for example, a concatenation of the string "vdr", the "vdrset” name, and the VDR number. For example, names could include “vdr-vdrsetl-1 ", "vdr- vdrse ⁇ 2-l ", etc.
  • the IP addresses assigned to the VDRs 1 18 will be drawn from the address pool assigned to a vdrset of which that VDR is a member.
  • the method 500 can further include creating an interface for the "intra” bridge of the VDR (step 504).
  • one end is named “intra-in” and the other is named as the concatenation of the string "intra”, the "vdrset” name, and the VDR number.
  • the "intra-vdrsetl-1” is assigned to the network namespace for this VDR, while the other half of the veth is assigned to the "intra” bridge.
  • the method 500 can also include creating an interface for the VDR bridge (step 504), which maps secured eridpoints to a particular VDR.
  • VDR bridge maps secured eridpoints to a particular VDR.
  • one end is named “seeured-in” and the other is named as the concatenation of the string “secured”, the "vdrset” name, and the VDR number.
  • the "secured-in” interface is assigned to the network namespace for this VDR, while the other half is assigned to a "secured” bridge.
  • a daemon such as daemon 306 of Fig. 3, is started (step 506), and routes are added by way of routing tables (step 508). Once routes are added, traffic can be managed by the daemon 306 among the interfaces as defined previously. Accordingly, the VDR is therefore configured to manage traffic for a particular cleartext endpoint.
  • FIG. 6 a flowchart of a method 600 for communicating with an external endpoint from a secure enterprise network, according to an example embodiment.
  • the method 600 represents general data traffic exchange across a cleartext gateway computing device 1 14 between a cleartext endpoint and one or more secured endpoints within a common community of interest as that cleartext endpoint.
  • the method 600 includes initiation of a VDR (e.g., VDR 1 18) for use in connection between such endpoints (step 602), such as endpoints 140, 160. This can be accomplished, for example, using the methods described above in connection with Figs. 4-5.
  • VDR e.g., VDR 1 18
  • endpoints 140, 160 e.g., endpoints 140, 160.
  • data is received at an interface (step 604). This can include receiving data at a cleartext interface 304 from a cleartext endpoint 160, or receiving data at a secure interface 302 from a secured endpoint 160, e.g., an endpoint within a Stealth-enabled secure enterprise network.
  • the method 600 includes routing the data to a complementary interface (step 606), for example via use of routing tables that define a routing between endpoints.
  • routing of data from a cleartext endpoint may require review of a routing definition between that endpoint and one or more endpoints within the secure enterprise network, as well as use of COI information (keys and filters) to determine the secured endpoints that are accessible to and visible to that cleartext endpoint.
  • COI information keys and filters
  • routing of data from a secured endpoint to a desired cleartext endpoint requires routing that data to the cleartext gateway computing device 1 14, which in turn determines, based on the intended endpoint (as noted based on addresses in the routing tables managed at that system) the intended cleartext endpoint; accordingly, an appropriate VDR is employed to communicate such data to the cleartext endpoint.
  • data addressed to a particular IP address assigned to a secure interface 302 of a VDR 1 18 results in forwarding of that data to the cleartext endpoint associated with that VDR,
  • a license status is monitored to determine whether a licensing tunnel is maintained open (step 608). This license polling may occur periodically, e.g., every 30 seconds. If the licensing tunnel remains open (branching OK), continued data exchange is allowed among endpoints 140, 160. However, if the license tunnel has been closed for a period of more than a predetennmed number of polling operations or minutes (branching Interrupted as shown in Fig. 6), each of the non-license VDRs established at the cleartext gateway computing device 1 14 are disabled and a reconnection process is triggered (step 610).
  • polling of the license VDR for an active license tunnel can occur more frequently, e.g., every 5 seconds, and a polling operation (step 608) can repeat. Once reconnection occurs, data exchange is again allowed by VDRs.
  • a clustering arrangement can be employed in which a clustering service monitors across a common set of networked cleartext gateway computing devices 1 14.
  • the clustering service can be managed on each of the devices, and is aware of the configuration of each device for data forwarding/management.
  • the clustering service can manage a cluster management network, separate from the cleartext and secured enterprise networks, ensuring that there is no commingling of cluster-specific network traffic with the secured or cleartext traffic.
  • clustering can be automatically started alongside instantiation of a cleartext gateway computing device 1 14, as part of method 400 of Fig. 4.
  • a separate clustering daemon can be included as part of the cleartext gateway computing device 1 14, and can monitor and check status of neighboring cleartext gateway computing devices, in some cases, a pool of TP addresses is reserved for clustered devices, and configurable using the administration tools exposed by the management interface 156.
  • FIGs. 7-10 various messaging flow diagrams are illustrated showing connectivity messages being passed among devices, such as the cleartext gateway, an authentication server, and a license server.
  • devices such as the cleartext gateway, an authentication server, and a license server.
  • Such devices can, in embodiments, correspond to the analogous devices of Figs. 1-3, above.
  • Fig. 7 is a messaging flow diagram 700 of a license VDR of a cleartext gateway computing device at an authentication service, according to an example embodiment.
  • a cleartext gateway device such as cleartext gateway device 1 14 of Fig. 1, transmits a tuples request to an authentication server, such as authentication sendee 133.
  • the authe tication server returns tuples to the gateway, with the tuples corresponding to keys useable to maintain a secure license tunnel open between the license VDR and a licensing server.
  • This can include, for example, key negotiation regarding settings, location, and other information associated with establishing a secure connection between a license VDR at the cleartext gateway device and the licensing server.
  • the returned tuples which may, in some embodiments, be encrypted with a wrapper key, are decrypted, and loaded into a license VDR at the cleartext gateway device.
  • the license VDR transmits a heartbeat message to the authentication server, which responds to the heartbeat message.
  • the heartbeat message, and response ensure continued connection between the authentication server and the cleartext gateway device, and ensures that the license counts tracked by the authentication server remains in sync with the license counts ti'acked at the cleartext gateway device, it does so by including tags for licenses and a total number of requested licenses in the heartbeat message.
  • An example heartbeat message can appear as follows:
  • the authe ication server will reply with a rekey command. Accordingly, the response to the heartbeat message by the authentication server will indicate one of a set of possible responses: (1) an indication that the license counts differs between the Auth Service and the SVGW; (2) an indication that the authentication server lias shut down the session associated with the cleartext gateway device, (3) an indication of a heartbeat failure between the authentication service and the license VDR, (4) a successful heartbeat response, or (5) an error. If the license count differs, a rekey response is transmitted, and the cleartext gateway device shuts down all running VDRs and restarts VDR authentication. Similarly, an indication that the authentication server has shut down the session will shut down running VDRs. Heartbeat failures, or errors, result in the license state being set to false.
  • Fig. 8 is a messaging flow diagram 800 of a VDR of a cleartext gateway device at an authentication service and licensing service, according to an example embodiment.
  • a tuples request is transmitted from the cleartext gateway device to the authentication server.
  • the tuples request will generally include information received from a remote cieartext endpoint, such as username and password or other authentication inrormation,
  • the authentication server determines whether a number of licenses lias changed, and if so, generates an adjusted total number of licenses associated with virtual machines (e.g., endpoints) that are connecting to a Stealth network via the cieartext gateway device.
  • virtual machines e.g., endpoints
  • the authentication server transmits a request for a total number of VDR licenses to a licensing server, such as licensing service 126 of Figs. 1-2, above.
  • the licensing server returns a response to the authentication server, which, based on a determination that an adequate number of total number of licenses exist, will generate and return a tuples response to the cieartext gateway device.
  • the tuples response will generally include community of interest information for the particular device seeking to connect via a cieartext connection to a VDR.
  • the cieartext gateway device will then load the tuples information (e.g., the received COI information) into a VDR that is allocated for the particular remote device..
  • the cieartext gateway device will also update a license count associated with the cieartext gateway in the license VDR.
  • the license VDR will send an updated heartbeat message to the authentication server which will in turn send back a response.
  • the heartbeat message can be as described above in connection with Fig. 7, but with an adjusted number of VDR licenses identified in the heartbeat message.
  • the Stealth network partitioned by COI and tied to particular sets of devices, that allows for cieartext communication from remote devices, while still ensuring that the remote devices cannot view (due to perfect forward secrecy) other devices within the Stealth network that are not part of the same cieartext COI.
  • Fig. 9 is a messaging flow diagram 900 of a VDR of a cieartext gateway device having existing licenses at an authentication service, according to an example embodiment.
  • the cieartext gateway device transmits a tuples request to the authentication server, which determines that a license is already earmarked for the particular VDR.
  • the authentication server returns a tuples response to the cieartext gateway device, which loads the tuples information (e.g., COI keys for the cieartext COI) into a VDR and updates the license VDR's license count.
  • the license VDR then transmits a heartbeat message and receives a response, as discussed above with respect to Fig. 7 (i.e., with unchanged license information, since the license was already allocated to the VDR).
  • Fig. 10 is a messaging flow diagram 1000 of a VDRs managed at a cleartext gateway device with an authentication server, according to an example embodiment
  • the messaging flow diagram 1000 occurs, for example, in response to a subsequent heartbeat message of the cleartext gateway device.
  • th e cleartext gateway device transmits the heartbeat message, as noted above in Fig. 7; the authentication server checks a total number of VDRs and number of licensed VDRs as identified in the heartbeat message, and generates a responsi ve message providing status of the licensing of VDRs at the cleartext gateway device, as also noted above.
  • Such a heartbeat message cycle can be performed on a configurable frequency, as set by one or both of the cleartext gateway device and the authentication server when provisioning the cleartext gateway device.
  • VDR states can include, for example, a null session state 1 102 (referred to as SESS_NONE), a VDR request state 1104 (SESS_REQ_VDR), an assigned VDR state 1 106 (SESS_ASSIGNED_VDR), a VDR provisioning request state 1 108 (8ES8 COI PROV REQ), and a VDR active state 1 1 10 (SESS_COI_ACTlVE).
  • SESS_NONE null session state 1 102
  • VDR request state 1104 SESS_REQ_VDR
  • SESS_ASSIGNED_VDR assigned VDR state 1 106
  • VDR provisioning request state 1 108 8ES8 COI PROV REQ
  • VDR active state 1 1 10 SESS_COI_ACTlVE
  • the null session state 3 102 represents a VDR in an available pool and lacking any routing or association with a VPN IP address. Such VDRs have a service key loaded and an associated IP address.
  • the assigned VDR state 1106 still has no routing, but has a service key loaded and includes IP addresses.
  • the assigned VDR state 1106 is associated with a VPN IP address, corresponding that VDR with a particular secure connection to a remote endpoint.
  • a VDR in the assigned VDR state still has no community of interest material (keys, etc.) assigned, so communication by the endpoint within the Stealth network (e.g., private domain 104) is not yet enabled.
  • the VDR broker 3 16 has assigned the VDR 1 18 with routing information, an associated VPN IP address, and community of interest material.
  • the VDR broker 116 has opened a license tunnel, allowing for validation of the COI material within the private domain 104, shown as a Stealth-enabled network.
  • an event manager included within the cleartext gateway device of the example embodiments described above tracks slate transitions among the various stales 1 102- 1 1 10, which may transition based on actions taken by the VDR broker 1 16.
  • Various actions may be performed, for example by a VDR. manager service operating within the cleartext gateway device.
  • actions can include:
  • a session creation action 1 120 (ACT CREATE SESSION), which creates a session entry and assigns a session. ID;
  • a request VDR action 1 122 (ACT_REQ_VDR), which corresponds to a VDR. request received at the VDR manager, and including a Client IP address and session ID.
  • the request VDR. action 1 122 triggers a CONNECTION_START event passing a usemame and IP address of the endpoint seeking connection at the cleartext gateway device, and handled by the VDR broker 1 16.
  • VDR assignment action 1124 (ACT_VDR_ASSIGN_COMPLETE), which reassigns a state to assign the VDR;
  • VDR provisioning action 1 126 (ACT PROV VDR), which sends a provision request to the VDR. manager;
  • VDR provisioning verification action 1 128 (ACT PROV COMPLETE), which resets a state of the VDR to active, as noted below:
  • VDR discarding action 1130 (ACT VDRJDISCARD), which issues a VDR discard request to the VDR manager;
  • VDR__ASS.1GN_.RSP Receipt of a VDR assignment response
  • VDR__ASS.1GN_.RSP Receipt of a VDR assignment response
  • the VDR assignment response can include, for example, a VDR. ID, securer public key, and VDR TP addresses.
  • An authentication completion indication (AUTII COMPLETE IND), corresponding to a message from the authentication manager that a Stealth user has been authenticated by the authentication service 133, includes a username, gateway, and COI response from the authentication server, and triggers the VDR provisioning action 1126, which in turn transitions the VDR to a VDR provisioning request state 1 108, From the VDR provisioning request state 1 108, a VDR provisioning verification action 1 128 will transition the VDR to a VDR active state 1 110, upon occurrence of a verification message (VDR_PROV_COMPLETE) from the VDR manager.
  • VDR_PROV_COMPLETE verification message
  • connection stop message (VPN_CO NECTION_STOP) indicating that a connection from the remote endpoint to the VDR has closed will cause transition to return to a VDR provisioning action 1 126, triggering attempts to re-provision the VDR with the associated mobile device upon reconnection of the VPN tunnel.
  • Fig. 1 1 generally, it is noted that although a particular set of states and state transitions are disclosed, other states or transitions may be provided as well, for example to accommodate tracking of different types of VDR connections, VPN connections, or to further define instances in which terminations occur to determine a cause of such terminations.
  • Fig. 12 illustrates a network topology 1200 incorporating a cleartext gateway device and allowing communication between cleartext endpoints and endpoints included in a secured enterprise network, according to an example embodiment.
  • the network topology 1200 illustrates an effect of establishing cleartext communications among various endpoints that are accessible to a cleartext portion of a Stealth-enabled network.
  • the network topology includes a cleartext gateway device 1202 that is communicatively connected to a plurality of cleartext endpoints 1240a-b at a public domain side of the cleartext gateway device 1202 and Stealth-based systems on a secured enterprise side of the cleartext gateway device 1202.
  • the secured enterprise side of the cleartext gateway device 1202 is connected to a plurality of endpoints 1232, shown as endpoints 12.32a-b.
  • the secured enterprise side of the cleartext gateway device 1202 is connected to an authentication server 1234 and a license server 1236.
  • each cleartext endpoint 1240a-b is associated with a particular public IP address.
  • cleartext endpoint 1240a is assigned 10.1.0.1
  • cleartext endpoint 1240b is assigned 10. i.0.2
  • each of the cleartext endpoints i240a-b addresses data to a particular VDR 1214; as shown in the example of Fig. 12, cleartext endpoint 1240a addresses VDR 1 1214a, while cleartext endpoint 1240b addresses VDR 2. 1214b.
  • the cleartext gateway device 1202 acts as a routing hop between the cleartext endpoint 1240 and the Stealth endpoint 1232.
  • VDR 1 1214a can then relay data to endpoints (e.g., one or both of Stealth endpoints 1232a-b), the selection of which being defined by the community of interest memberships defined at the authentication server 1234.
  • endpoints e.g., one or both of Stealth endpoints 1232a-b
  • those endpoints 1232 that are part of a common community of interest with a cleartext endpoint 1240 can directly address that cleartext endpoint 1240 by addressing data to the external IP address defined at the cleartext endpoint 1240, rather than requiring addressing of the VDR associated with that endpoint.
  • Stealth endpoint 1232a can transmit data to cleartext endpoint 1240a by transmitting data to IP address 10, 1.0.1. That TP address is also assigned, within the Stealth network side of the cleartext gateway device 1202, to the VDR 1214a associated with the cleartext endpoint 1240a assigned that IP address.
  • two or more cleartext endpoints 1240 may each be configured to allow for cleartext access to Stealth endpoints 1232, such access is not necessarily common across those Stealth endpoints 1232, but is rather defined b the cleartext communities of interest associated with those endpoints.
  • COI keys and filters loaded into VDR 1 1214a may allow access by cleartext endpoint 1240 to both Stealth endpomts 1232a-b, while a separate set of COI keys and filters loaded into VDR 2 1214b (defined by the usemame and access credentials of a user at cleartext endpoint 1240b, and as stored in authentication server 1234) may only allow access to Stealth endpoint 1232b and not to Stealth endpoint 1232a.
  • Various arrangements of cleartext communities of interest may be configured within the network topology 1200, as defined within the authentication server 1234.
  • the license VDR may cause disconnection or shutdown of the VDRs 1214 entirely, interrupting communication between Stealth endpoints 1232 and cleartext endpoints 1240.
  • VDRs 1214 implement VDRs 1214 in a "flat" configuration
  • VDRs could be pooled to allow access to various sub-segments of a Stealth network.
  • VDR sets could be addressed in ranges, with each range being associated with a set of VDRs and associated accessible Stealth endpoints.
  • FIG. 13 illustrates a computer system 1300 adapted according to certain embodiments of the gateway computing device, server and/or the user interface device.
  • the central processing unit (“CPU") 702 is coupled to the system bus 1304.
  • the CPU 1302 may be a general purpose CPU or microprocessor, graphics processing unit (“GPU”), and/or microcontroller.
  • the present embodiments are not restricted by the architecture of the CPU 1302 so long as the CPU 1302, whether directly or indirectly, supports the operations as described herein.
  • the CPU 1302 may execute the various logical instructions according to the present embodiments.
  • the computer system 1300 also may include random access memory (RAM) 1308, which may be synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), or the like. Tne computer system 1300 may utilize RAM 1308 to store the various data structures used by a software application.
  • the computer system 1300 may also include read only memory (R OM) 1306 which may be PROM, EPROM, EEPRDM, optical storage, or the like.
  • R OM read only memory
  • the ROM may store configuration information for booting the computer system 1300.
  • the RAM 1308 and the ROM 1306 hold user and system data, and both the RAM 1308 and the ROM 1306 may be randomly accessed.
  • the computer system 1300 may also include an input/output (I/O) adapter 1310, a communications adapter 1314, a user interface adapter 1316. and a display adapter 1322.
  • the I/O adapter 1310 and/or the user interface adapter 1316 may, in certain embodiments, enable a user to interact with the computer system 1300.
  • the display adapter 1322 may display a graphical user interface (GUI) associated with a software or web-based application on a display device 1324, such as a monitor or touch screen.
  • GUI graphical user interface
  • the I/O adapter 1310 may couple one or more storage devices 1312, such as one or more of a hard drive, a solid state storage device, a flash drive, a compact disc (CD) drive, a floppy disk drive, and a tape drive, to the computer system 1300.
  • the data storage 1312 may be a separate server coupled to the computer system 1300 through a network connection to the I/O adapter 1310.
  • the communications adapter 1314 may be adapted to couple the computer system 1300 to the network 1409, which may be one or more of a LAN, W AN, and/or the Internet.
  • the communications adapter 1314 may also be adapted to couple the computer system 1300 to other networks such as a global positioning system (GPS) or a Bluetooth network.
  • the user interface adapter 1316 couples user input devices, such as a keyboard 1320, a pointing device 1318, and/ or a touch screen (not shown) to the computer system 1300.
  • the keyboard 1320 may be an on-screen keyboard displayed on a touch panel.
  • Additional devices such as a camera, microphone, video camera, accelerometer, compass, and or gyroscope may be coupled to the user interface adapter 1316.
  • the display adapter 1322 may be driven by the CPU 1302 to control the display on the display device 1324. Any of the devices 1302- 1322 may be physical and/or logical.
  • the applications of the present disclosure are not limited to the architecture of computer system 1300.
  • any suitable processor-based device may be utilized including, without limitation, personal data assistants (PDAs), tablet computers, smartphones, computer game consoles, and multi-processor servers.
  • PDAs personal data assistants
  • the systems and methods of the present disclosure may be implemented on application specific integrated circuits (ASIC), very large scale integrated (VLSI) circuits, or other circuitry.
  • ASIC application specific integrated circuits
  • VLSI very large scale integrated circuits
  • persons of ordinar skill in the art may utilize any number of suitable structures capable of executing logical operations according to the described embodiments.
  • the computer system 1300 may be virtualized for access by multiple users and/or applications.
  • Fig. 14 is a block diagram illustrating a server hosting an emulated software environment for virtualizat on according to one embodiment of the disclosure.
  • An operating system 1402 executing on a server includes drivers for accessing hardware components, such as a networking layer 1404 for accessing the communications adapter 1314.
  • the operating system 1402 may be, for example, Linux.
  • An emulated environment 1408 in the operating system 1402 executes a program 1410, such as CPCommOS.
  • the program 1410 accesses the networking layer 804 of the operating system 1402 through a non-emulated interface 1406, such as XNIOP.
  • the non-emulated interface 1406 translates requests from the program 1410 executing in the emulated environment 1408 for the networking layer 1404 of the operating system 1402.
  • Fig. 15 is a block diagram illustrating a server hosting an emulated hardware environment according to one embodiment of the disclosure.
  • Users 1452, 1454, 1456 may access the hardware 1460 through a hypervisor 1458.
  • the hypervisor 1458 may be integrated with the hardware 1460 to provide virtualization of the hardware 1460 without an operating system, such as in the configuration illustrated in Fig. 13.
  • the hypervisor 1458 may provide access to the hardware 1460, including the CPU 1302 and the communications adapter 1314.
  • Computer-readable media includes physical computer storage media.
  • a storage medium may be any available medium that can be accessed by a computer.
  • such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.
  • Disk and disc includes compact discs (CD), laser discs, optical discs, digital versatile discs (DVD), floppy disks and Blu-ray discs. Generally, disks reproduce data magnetically, and discs reproduce data optically. Combinations of the above should also be included within the scope of computer-readable media.
  • Computer storage media generally includes at least some tangible, non-transitory media and can, in some embodiments, exclude transitory wired or wireless signals.
  • Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media.
  • modulated data signal may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal.
  • communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as Wi-Fi, acoustic, radio frequency (RF), infrared, and other wireless media.
  • the term computer readable media as used herein may include computer storage media, but generally excludes entirely transitory embodiments of communication media, such as modulated data signals.
  • instructions and/or data may be provided as signals on transmission media included in a communication apparatus.
  • a communication apparatus may include a transceiver having signals indicative of instructions and data. The instructions and data are configured to cause one or more processors to implement the functions outlined in the claims,
  • Figs. 1-14 generally, it is noted that the arrangements described herein provide a number of advantages over existing arrangements in terms of security, convenience, forward-compatibility, and flexibility for use with external, unaffiliated systems. For example, because of the use of dedicated VDRs for each external endpoint, the security settings of a particular private domain can be extended to that external endpoint (and data can be seamlessly communicated among VMs in the private and cloud environments) without a requirement of sharing community of interest keys or filters to the external computing system, ensuring the security of those keys and filters.
  • trusted remote systems such as remote trusted mobile devices
  • direct connection via a eleartext gateway is possible, thereby enabling communication between such devices and secure enterprise networks even in instances where the device exists within the secure enterprise network and secure connection (e.g., via VPN) is not typically performed,

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un système informatique de passerelle qui comprend une mémoire stockant un logiciel de passerelle de texte en clair et un circuit programmable connecté en communication à la mémoire. Le circuit programmable est configuré pour exécuter des instructions pouvant être exécutées par ordinateur comprenant le logiciel de passerelle de texte en clair. L'exécution du logiciel de passerelle de texte en clair par le circuit programmable amène le système informatique de passerelle à instancier, au niveau du système informatique de passerelle, un routeur de dispositif virtuel comprenant une interface de texte en clair configurée pour envoyer et recevoir des paquets de données à partir d'un point d'extrémité de texte en clair, et une interface sécurisée configurée pour échanger des paquets de données avec un ou plusieurs points d'extrémité sécurisés dans un réseau d'entreprise sécurisé, et à charger le routeur de dispositif virtuel avec un matériel de communauté d'intérêt provenant d'un serveur d'authentification, le matériel de communauté d'intérêt étant associé à une ou plusieurs communautés d'intérêt configurées pour permettre un accès au point d'extrémité de texte en clair.
PCT/US2015/038283 2014-06-30 2015-06-29 Passerelle de texte en clair pour des communications d'entreprise sécurisées Ceased WO2016003885A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201462018802P 2014-06-30 2014-06-30
US62/018,802 2014-06-30
US14/753,437 US20150381567A1 (en) 2006-01-26 2015-06-29 Cleartext gateway for secure enterprise communications
US14/753,437 2015-06-29

Publications (1)

Publication Number Publication Date
WO2016003885A1 true WO2016003885A1 (fr) 2016-01-07

Family

ID=55019873

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/038283 Ceased WO2016003885A1 (fr) 2014-06-30 2015-06-29 Passerelle de texte en clair pour des communications d'entreprise sécurisées

Country Status (1)

Country Link
WO (1) WO2016003885A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110381014A (zh) * 2019-06-03 2019-10-25 广东元一科技实业有限公司 用于提供安全和冗余通信的系统和方法
US12074768B1 (en) 2021-09-09 2024-08-27 T-Mobile Usa, Inc. Dynamic configuration of consensus-based network

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153642A1 (en) * 2002-05-14 2004-08-05 Serge Plotkin Encryption based security system for network storage
US20120084566A1 (en) * 2010-10-04 2012-04-05 Edward Chin Methods and systems for providing and controlling cryptographic secure communications across unsecured networks
EP2648098A2 (fr) * 2012-04-05 2013-10-09 Cisco Technology, Inc. Système et procédé de migration de machines virtuelles d'application dans un environnement de réseau
WO2014011374A1 (fr) * 2012-07-12 2014-01-16 Unisys Corporation Isolation cryptographique de machines virtuelles
US20140157042A1 (en) * 2012-11-30 2014-06-05 Robert A. Johnson Load balancing and failover of gateway devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153642A1 (en) * 2002-05-14 2004-08-05 Serge Plotkin Encryption based security system for network storage
US20120084566A1 (en) * 2010-10-04 2012-04-05 Edward Chin Methods and systems for providing and controlling cryptographic secure communications across unsecured networks
EP2648098A2 (fr) * 2012-04-05 2013-10-09 Cisco Technology, Inc. Système et procédé de migration de machines virtuelles d'application dans un environnement de réseau
WO2014011374A1 (fr) * 2012-07-12 2014-01-16 Unisys Corporation Isolation cryptographique de machines virtuelles
US20140157042A1 (en) * 2012-11-30 2014-06-05 Robert A. Johnson Load balancing and failover of gateway devices

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110381014A (zh) * 2019-06-03 2019-10-25 广东元一科技实业有限公司 用于提供安全和冗余通信的系统和方法
US12074768B1 (en) 2021-09-09 2024-08-27 T-Mobile Usa, Inc. Dynamic configuration of consensus-based network

Similar Documents

Publication Publication Date Title
US20150381567A1 (en) Cleartext gateway for secure enterprise communications
US9294443B2 (en) Secure integration of hybrid clouds with enterprise networks
US10454931B2 (en) Secure remote access for secured enterprise communications
US10129092B2 (en) Enabling cross-realm authentication between tenant and cloud service provider
US10009443B1 (en) Provisioning remote application servers on a service provider infrastructure as a service platform
US10776489B2 (en) Methods and systems for providing and controlling cryptographic secure communications terminal operable to provide a plurality of desktop environments
US20190058706A1 (en) Extending Single-Sign-On to Relying Parties of Federated Logon Providers
JP2022533890A (ja) 異なる認証クレデンシャルを有する認証トークンに基づいてセッションアクセスを提供するコンピューティングシステムおよび方法
US9912663B2 (en) Enabling secure network mobile device communications
JP2019526843A (ja) ホストされたアプリケーションへの動的アクセス
US10771309B1 (en) Border gateway protocol routing configuration
JP7027612B2 (ja) ヘルパを介したクライアントデバイスの匿名セッションへの接続
JP2022533891A (ja) レガシー仮想配信アプライアンスとともに使用するための接続リーシングシステムおよび関連方法
JP2021535521A (ja) 仮想デスクトップでのローカルマップアカウント
US10735387B2 (en) Secured network bridge
WO2023197942A1 (fr) Procédé d'extension de nuage public, dispositif, système et support de stockage
AU2018216671B2 (en) Service endpoint interconnect in a virtual private gateway
US9794225B2 (en) Secure network communications in a mobile device over IPsec
EP3288235B1 (fr) Système et appareil pour garantir le respect d'un accord de niveau de service (sla) dans un environnement cloud via l'utilisation de signature électronique
WO2016003885A1 (fr) Passerelle de texte en clair pour des communications d'entreprise sécurisées
JP2022516290A (ja) 汚染された接続エージェントの追跡
WO2016003566A1 (fr) Intégration sécurisée de nuages hybrides avec des réseaux d'entreprise
US20250119418A1 (en) Connection establishment using shared certificate in global server load balancing (gslb) environment
WO2016003860A1 (fr) Communications de réseau sécurisé dans un dispositif mobile sur ipsec
CN120872482A (zh) 用于对计算基础设施进行自动化部署的方法和系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15736148

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15736148

Country of ref document: EP

Kind code of ref document: A1