Patent Application
20150381567
The present disclosure relates generally to security arrangements for cloud computing. In particular, the present disclosure relates to a cleartext gateway for secure enterprise communications.
Modern organizations generate store, and communicate large quantities of data. In many instances, organizations include individuals having 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. In addition, it is frequently important that 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.
To address the above issues, Unisys Corporation of Blue Bell, Pa. 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”. However, 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. Most recently, the Stealth solution has been extended to accommodate usage of an “off the shelf” Internet Protocol Security (IPsec)-based security protocol as a basis for some aspects of the Stealth solution. IPsec is an end-to-end security scheme of the Internet Protocol Suite. As compared to other security systems, such as SSL, SSH, or TLS, IPsec operates in the Internet Layer rather than operating in the upper layers of the TCP/IP model. Hence, 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-enabled networks.
However, existing 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”. Furthermore, 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. Furthermore, different implementations of IPsec on different types of computing systems are handled differently, leading to inconsistencies in connection parameters. Furthermore, 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. However, to accomplish perfect forward secrecy, such trading of security parameters may not be possible.
Accordingly, mechanisms for improving flexibility by which devices can connect to and communicate with other devices within a Stealth-based network are desirable.
In summary, the present disclosure relates generally to security arrangements for cloud computing. In particular, the present disclosure relates to a cleartext gateway for secure enterprise communications.
In a first aspect, 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 endpoint 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 endpoint.
In a second aspect, 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.
In a third aspect, a secured enterprise network allowing connection to a cleartext endpoint is disclosed. 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.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
As briefly described above, 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. 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. In some embodiments, 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.
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. Within a network, the virtual machines may be logically organized into a number of community-of-interest (COI) groups. Each COI may use an encryption key to secure communications within the COI, such that only other endpoints in the COI 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. As noted in the above-cited patents and patent applications, use of the COI groups, and associated authentication, allows for complete opacity of a network for devices not belonging to a COI group, allowing a secured enterprise network to appear to have different computing system endpoints therewithin based on the COI to which that endpoint or device belongs.
In the context of the present disclosure, 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. Such 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. Furthermore, 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).
According to example embodiments discussed herein, endpoints, such as virtual machines, in a network may be isolated by encrypting transmissions between the endpoints with keys possessed only by an intended recipient. Within a network, the endpoints may be logically organized into a number of community-of-interest (COI) groups. Each COI may use an encryption key to secure communications within the COT, such that only other virtual machines in the COI 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 information may be created based on a template stored on a configuration server.
In particular embodiments, 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, Pa. 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. Example arrangements in which a cleartext gateway may be used are illustrated in connection with
Referring now to
In the embodiment shown, 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 virtualized component 106, and an enterprise support component 108. Generally, the architecture represents computing resources available to an enterprise for managing, for example, computing or storage tasks.
In the embodiment shown, the cloud domain 102 includes a plurality of configurable cloud-based virtual machines 110 (shown as virtual machines, or VMs, 110a-b). The cloud-based virtual machines 110 can be configured for use in connection with a common virtual network, or vLAN 112, 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 114, as discussed below, for communication with locally-managed virtual machines within the private domain 104. Although in the present disclosure two cloud-based VMs 110a-b are shown, it is noted that other virtual machines, and associated in two or more vLAN arrangements, could be used as well.
In addition, in the embodiment shown, 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, Pa. Example operation of such a device is described in a number of applications, including: U.S. Provisional Patent Application No. 61/389,511, filed Oct. 4, 2010, and entitled “System and Method for Providing a USB Stick-Based Thin Client”, Attorney Docket No. TN521.P, the disclosure of which is hereby incorporated by reference in its entirety; U.S. Provisional Patent Application No. 61/389,535, filed Oct. 4, 2010, and entitled “System and Method for Providing a Stealth Secure Virtual Terminal”, Attorney Docket No. TN533.P, the disclosure of which is hereby incorporated by reference in its entirety; and U.S. patent application Ser. No. 11/714,598, filed Mar. 6, 2007, entitled “Gateway for Securing Data to/from a Private Network”, Attorney Docket No. TN400.US-CIP3, the disclosure of which is hereby incorporated by reference in its entirety. Accordingly, communication with such devices, since secured using Stealth-based communications and pre-configured with licensing connection information, does not require a secure connection for communication with a gateway, particularly when positioned within and communicating from within an enterprise network. In such instances, 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. Accordingly, for such connections, rather than connecting to a gateway device that implements VDRs (discussed in further detail below) providing a secured VPN-based interface, a cleartext gateway device is provided herein that implements a cleartext interface by which such devices can connect to trusted devices within the private domain 104.
In private domain 104, a gateway device 114 provides a communication location for external endpoints, such as endpoint 140 or cloud-based VMs 110, to coordinate communication with private domain systems. The broker 116, included within gateway device 114 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 118, 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 110. As noted below, use of such VDRs 118 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 cleartext interface via the gateway device 114 to a cloud-based VM 110 for communication over the internet. Details regarding a cleartext implementation of the gateway device 114 and associated broker 116 are discussed in further detail below in connection with
When initially installed, the gateway device 114 and broker 116 can be configured to provide cleartext communications to an external endpoint, as well as Stealth-based secure communications with other private domain systems. The broker 116 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.
In addition, in the embodiment shown, a credentialing service 122 can be provided that connects to the gateway device 114 and the broker 116 via a management vLAN 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 114. Using the credentialing service 122, credentials specific to their purpose are provided at boot time, used immediately to authenticate a VM and authorize its COIs, and then the credentials are discarded. Use and discarding of credentials after authentication prevents replay attacks, duplicating VMs, and RAM/VM scraping for credentials.
In addition, within the private domain 104, a plurality of private domain virtual machines 124 (shown as VMs 124a-b) can be maintained. These VMs 124 can be within the same or different COIs to each other and to the cloud-based VMs 110 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 110, 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.
In some embodiments, 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. In particular, 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 authentication 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 virtualized 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. In example embodiments, 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 110, cleartext endpoints such as endpoint 140 connected via the cloud domain 102, and VDRs 118 used to communicate with such cloud-based VMs and other devices in the cloud domain 102.
Using the authentication service 133, cloud-based VMs 110, as well as other external endpoints (e.g., endpoint 140), are authenticated and authorized. In the context of a secured connection to an external endpoint, a first authorization is to authenticate the IPsec VPN connection and authorize the corresponding VDR's COIs, providing the VDR 118 that is associated with each particular VM 110 with COI keys and filters. However, a second authentication is to authenticate a logon service of the VM 110, and authorize cloud-based COIs 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). For example, the logon service can be authenticated using an Active Directory instance or via an authentication performed from the enterprise domain.
It is noted that 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. For example, in some cases, the authentication service 133 may be configured to validate individual VDR traffic from VDRs 118 at the gateway device 114, or multiple devices 114 may be included in a network. Accordingly, an XML file can designate a particular authorization group and can be loaded at respective gateway devices 114 to associate those devices with a particular authentication service 133.
In the embodiment shown, 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). In example embodiments, the security appliance 134 could alternatively be used as the licensing service 126. In still other embodiments, the security appliance 134 can be removed altogether (e.g., in entirely IPsec-based implementations).
Referring back to the cloud-based VMs 110, in the embodiment shown, a cloud-based VM can include an applet 131 that stores service mode credentials 132 useable to initiate authentication of the cloud-based VM 110. Additionally, the service mode credentials 132 can be used to obtain service mode keys and/or filters useable to access the authentication service 133, 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 110 or endpoint 140 can be accomplished via the applet 131.
Referring to
Furthermore, and still referring to
Referring now to
In the embodiment shown, the cleartext gateway computing device 114 includes a broker 116, as well as a plurality of cleartext VDRs 118a-b. The broker 116 corresponds to a service useable to manage the cleartext VDRs 118a-b, including creation of such VDRs for use with 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 COI information 119a-b which corresponds to the COIs associated with the users of the cleartext endpoints 140a-b. Accordingly, even though a cleartext connection is established between corresponding VDRs 118a-b and respective cleartext endpoints 140a-b, the COI information 119a-b, respectively expose only particular secured endpoints 160 (e.g., VMs or physical computing systems) within the secure enterprise network 202. The COI information 119a-b is retrieved from the authentication service 133 during authentication of the cleartext endpoint to the cleartext gateway computing device 114, as noted below in conjunction with
In the embodiment shown, the cleartext gateway computing device 114 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 gateway computing device 114; as explained below, upon disconnection of the license VDR 150 from the licensing service 126, the broker 116 halts operation of each of the cleartext VDRs 118a-b until communication with the licensing service 126 can be reestablished.
A routing table 152 is established in the cleartext gateway computing device 114, and is used for routing traffic exchange to and from secured endpoints 160 from the cleartext endpoints 140a-b via VDRs 118a-b. For example, the routing table 152 maintains network addresses of the cleartext endpoints 140a-b, as well as for secured endpoints 160. Additionally, the routing table 152 manages IP addresses for each of the VDRs 118a-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
In accordance with example embodiments of the present disclosure, each VDR 118 is assigned a number of attributes for use within the secure enterprise network 202. Such 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 rules required to map traffic between a cleartext endpoint 140 and secured endpoints 160 for authorized COIs. It also provides an administrative interface for management of the cleartext gateway computing device 114. The administrative interface can be, in some embodiments, a command line interface by which an administrative user can inquire into the status of VDRs 118 within the cleartext gateway computing device 114 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 show interfaces for each VDR and the status of such interfaces. In some instances, the control daemon 154 may perform SSH or other authentication services, may manage system logs using a syslog API, set firewall rules 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.
In example embodiments, the control daemon 154 includes a plurality of subordinate threads which assist in governing operation of the cleartext gateway computing system 114. 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, Pa.) for each VDR by obtaining COI material and filter rules from the authentication service 133 for that VDR. In addition, 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.
In some instances, the cleartext gateway computing device 114 includes a provisioning utility installed thereon that delivers endpoint software useable within a Stealth-enabled network, allowing the gateway device 114 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 114 Stealth-based security credentials for VDRs that may be instantiated at the cleartext gateway computing device 114.
In addition to the above, the cleartext gateway computing device 114 can be configured to perform one or more logging or management operations via management interface 156. For example, a dump utility could be included to assemble configuration, logs, and other feedback into a single file to be used for system troubleshooting. Additionally, an enterprise management agent could be used to monitor operational statistics of the cleartext gateway computing device 114, for example to provide to a management server within the secure enterprise network. Finally, 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.
In operation, the cleartext gateway computing device 114 makes data forwarding decisions based on values in the packet, rather than only the destination address. For example, the kernel provides an ordered set of rules containing matching criteria which are evaluated to determine the routing table to employ for the frame. Using this mechanism 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 114 to relay frames for a given cleartext endpoint 140 through a particular VDR 118.
Overall, the cleartext gateway computing device 114 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 114, 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 114, 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. In addition, global routes, system logging settings (options and names), availability/clustering parameters and names, and cleartext mappings between VDRs and cleartext endpoints (e.g., including cleartext maps, lists of cleartext hosts, etc.) can be tracked. Other options are possible as well.
In example embodiments, each cleartext endpoint 140 and associated VDR 118 forming a clear text subnet will include an IP address for the cleartext gateway computing device 114, 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.
In example embodiments, a daemon 306 is instantiated as part of the VDR 118, and controls communication via the secure interface. In example embodiments, 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.
Referring to
In example embodiments, two or more 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). 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.
Referring now to
In the embodiment shown, for each VDR included at the cleartext gateway computing device 114, IP addresses are assigned to a secure interface and a cleartext interface portion of the VDR (step 404). For example, in some embodiments 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. In such cases, each bridge device is assigned an IP address. For each 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.
In the embodiment shown, 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 COI key material used by the license VDR to establish the license tunnel.
Once the license tunnel is established, 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., COI keys and filters associated with the user of the cleartext endpoint with which the VDR is used). Once the COI information is loaded in the respective VDR (e.g., into a secure daemon associated with the VDR), the cleartext gateway computing device 114 can determine whether the license tunnel remains established. The VDR will apply filter rules based on the received COI information, and the VDR will be set to a “pending license” state.
The method 400 accordingly includes loading COI information (e.g., keys and filter rules) associated with each example COI into the corresponding VDR. For example, if a first VDR is associated with a cleartext endpoint 140 intended to have access to computing systems or other endpoints within COI A of the secure enterprise network, and a second VDR is associated with a different cleartext endpoint 140 intended to have access to computing systems or other endpoints within COI B of the secure enterprise network, each VDR will obtain COI keys and filter lists associated with that COI and endpoint, respectively, and apply those at the first and second VDRs. Accordingly, a first cleartext endpoint will access only endpoints within COI A through an associated VDR, while a second cleartext endpoint will access only endpoints within COI B through a different associated VDR.
In example embodiments, once license and COI information is loaded and initialized, startup of the VDR can then be triggered (step 410), for example by execution of a “hook script”. Such hook scripts allow an arbitrary program to be executed at stages during the execution process of the control daemon 154. They can be used to add arbitrary routes or filter rules. In some embodiments, 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 114 include a startup hook script, which initiates startup of the cleartext gateway computing device 114, a shutdown hook script which terminates operation of the cleartext gateway computing device 114, or an interface up hook script, which receives an identification of an interface and enables that interface.
In the embodiment shown, the method 500 can further include creating an interface for the “intra” bridge of the VDR (step 504). In example implementations, 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. For example, “intra-vdrset1-1”. In such cases, the “intra-in” interface is assigned to the network namespace for this VDR, while the other half of the veth is assigned to the “intra” bridge.
In the embodiment shown, the method 500 can also include creating an interface for the VDR bridge (step 504), which maps secured endpoints to a particular VDR. In an example implementation, one end is named “secured-in” and the other is named as the concatenation of the string “secured”, the “vdrset” name, and the VDR number. For example, “secured-vdrset1-1”. In such cases, 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
Referring now to
In the embodiment shown, the method 600 includes initiation of a VDR (e.g., VDR 118) 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
In the embodiment shown, 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. For example, 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. Similarly, routing of data from a secured endpoint to a desired cleartext endpoint requires routing that data to the cleartext gateway computing device 114, 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. In some scenarios, data addressed to a particular IP address assigned to a secure interface 302 of a VDR 118 results in forwarding of that data to the cleartext endpoint associated with that VDR.
In addition to routing of data, during operation of the cleartext gateway computing device 114, maintenance of a licensing tunnel is monitored. In the example shown, 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 predetermined number of polling operations or minutes (branching Interrupted as shown in
It is noted that because the cleartext gateway computing device 114 requires a separate VDR for each cleartext endpoint 140, it may be advisable to employ more than one such cleartext gateway computing device 114, depending upon the number of cleartext endpoints to be accommodated. In such examples, a clustering arrangement can be employed in which a clustering service monitors across a common set of networked cleartext gateway computing devices 114. 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.
In some embodiments, clustering can be automatically started alongside instantiation of a cleartext gateway computing device 114, as part of method 400 of
Referring now to
Once the license VDR is loaded with such connectivity information, it 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 tracked 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:
If the cleartext gateway device reports a license count that is out of sync with the authentication server, then the authentication 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 has 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.
The authentication server then transmits a request for a total number of VDR licenses to a licensing server, such as licensing service 126 of
Referring now to
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. However, 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. In the VDR active state 1110, the VDR broker 116 has assigned the VDR 118 with routing information, an associated VPN IP address, and community of interest material. Furthermore, 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.
In operation, an event manager included within the cleartext gateway device of the example embodiments described above tracks state transitions among the various states 1102-1110, which may transition based on actions taken by the VDR broker 116. Various actions may be performed, for example by a VDR manager service operating within the cleartext gateway device. In example embodiments, actions can include:
In the null session state 1102, receipt of a start connection request will cause the broker 116 to perform a session creation action 1120, transitioning the VDR to the VDR request state 1104. Receipt of a VDR assignment response (VDR_ASSIGN_RSP), which indicates that a VDR has been allocated, can trigger the VDR assignment action 1124, and, upon a VDR assignment action 1124 (ACT_VDR ASSIGN_COMPLETE), transition to the assigned VDR state 1106. The VDR assignment response can include, for example, a VDR ID, securer public key, and VDR IP addresses.
An authentication completion indication (AUTH_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 1108. From the VDR provisioning request state 1108, a VDR provisioning verification action 1128 will transition the VDR to a VDR active state 1110, upon occurrence of a verification message (VDR_PROV_COMPLETE) from the VDR manager. From the VDR active state 1110, a connection stop message (VPN_CONNECTION_STOP) indicating that a connection from the remote endpoint to the VDR has closed will cause transition to return to a VDR provisioning action 1126, triggering attempts to re-provision the VDR with the associated mobile device upon reconnection of the VPN tunnel.
Additionally, when in any of states 1106-1112, performance of a cleanup action 1132, or in states 1108-1112 performance of a VDR discarding action 1130, will transition the VDR to a null session state 1102, returning the VDR to an available pool by turning off all routing, disabling workgroups, and disassociating a VPN IP address (thereby disassociating the VDR from the mobile device and associated application). Such terminations may occur, for example, in response to a termination message received from the authentication manager.
Referring to
Additional details regarding transition of states, and example services within a gateway that can perform such state transitions, are discussed in further detail in U.S. patent application Ser. No. ______, filed herewith, Attorney Docket No. TN624, and U.S. Provisional Patent Application No. 62/018,956, filed on Jun. 30, 2014, Attorney Docket No. TN624.P, the disclosures of both of which is hereby incorporated by reference in their entireties.
As illustrated, each cleartext endpoint 1240a-b is associated with a particular public IP address. For example, as seen in
While license VDR 1233 maintains a license connection to a license server 1236 and adequate licenses exist, the VDRs 1214a-b will be allocated cleartext licenses, and assigned COI information. Accordingly, VDR 11214a 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. Similarly, 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. Accordingly, for example Stealth endpoint 1232a can transmit data to cleartext endpoint 1240a by transmitting data to IP address 10.1.0.1. That IP 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.
It is noted that, although 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 by the cleartext communities of interest associated with those endpoints. For example, COI keys and filters loaded into VDR 11214a may allow access by cleartext endpoint 1240 to both Stealth endpoints 1232a-b, while a separate set of COI keys and filters loaded into VDR 21214b (defined by the username 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.
Furthermore, to the extent the license server 1236 loses a connection to license VDR 1233, the license VDR may cause disconnection or shutdown of the VDRs 1214 entirely, interrupting communication between Stealth endpoints 1232 and cleartext endpoints 1240.
Although in the embodiment shown the cleartext gateway device 1202 implements VDRs 1214 in a “flat” configuration, it is understood that in some embodiments, such VDRs could be pooled to allow access to various sub-segments of a Stealth network. In such embodiments, VDR sets could be addressed in ranges, with each range being associated with a set of VDRs and associated accessible Stealth endpoints.
Referring to
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. The 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 (ROM) 1306 which may be PROM, EPROM, EEPROM, optical storage, or the like. 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. In a further embodiment, 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.
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. According to one embodiment, 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, WAN, 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 (not shown) 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. For example, 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. Moreover, 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. In fact, persons of ordinary skill in the art may utilize any number of suitable structures capable of executing logical operations according to the described embodiments. For example, the computer system 1300 may be virtualized for access by multiple users and/or applications.
In another example, hardware in a computer system may be virtualized through a hypervisor.
If implemented in firmware and/or software, the functions described above may be stored as one or more instructions or code on a computer-readable medium. Examples include non-transitory computer-readable media encoded with a data structure and computer-readable media encoded with a computer program. Computer-readable media includes physical computer storage media. A storage medium may be any available medium that can be accessed by a computer. By way of example, and not limitation, 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. The term “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. By way of example, and not limitation, 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. In accordance with the present disclosure, 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.
In addition to storage on computer readable medium, instructions and/or data may be provided as signals on transmission media included in a communication apparatus. For example, 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.
Although the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the present invention, disclosure, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present disclosure. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
Referring to
The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
The present application claims priority from U.S. Provisional Patent Application No. 62/018,802 filed on Jun. 30, 2014, Attorney Docket No. TN622.P, the disclosure of which is hereby incorporated by reference in its entirety. The present application is also related to, and claims priority from the following related and commonly assigned U.S. patent applications: 1. U.S. Provisional patent application entitled: Distributed Security on Multiple Independent Networks using Secure “Parsing” Technology, by Robert Johnson, Attorney Docket No. TN400.P, Ser. No. 60/648,531, filed 31 Jan., 2005; 2. U.S. patent application entitled: Integrated Multi-Level Security System, by Robert Johnson, Attorney Docket No. TN400.U.S. Ser. No. 11/339,974 filed 26 Jan. 2006 claiming the benefit of the above provisional applications; 3. U.S. patent application entitled: Integrated Multi-Level Security System, by Robert Johnson et al., Attorney Docket No. TN400.USCIP1, Ser. No. 11/714,590 filed 6 Mar. 2007 which is a continuation-in-part of U.S. application Ser. No. 11/339,974; 4. U.S. patent application entitled: Integrated Multi-Level Security System, by Robert Johnson et al., Attorney Docket No. TN400.USCIP2, Ser. No. 11/714,666 filed 6 Mar. 2007 which is a continuation-in-part of U.S. application Ser. No. 11/339,974; and 5. U.S. patent application entitled: Integrated Multi-Level Security System, by Robert Johnson et al., Attorney Docket No. TN400.USCIP3, Ser. No. 11/714,598 filed 6 Mar. 2007 which is a continuation-in-part of U.S. application Ser. No. 11/339,974. 6. U.S. patent application Ser. No. 12/272,012, entitled “Block Level Data Storage Security System”, filed 17 Nov. 2008, Attorney Docket No. TN497. The present disclosure also claims the benefit of commonly assigned U.S. patent application Ser. No. 12/336,558, entitled “Data Recovery Using Error Strip Identifiers”, filed 17 Dec. 2008, Attorney Docket No. TN494. 7. U.S. patent application Ser. No. 12/336,559 entitled “Storage Security Using Cryptographic Splitting”, filed 17 Dec. 2008, Attorney Docket No. TN496; U.S. patent application Ser. No. 12/336,562, entitled “Storage Security Using Cryptographic Splitting”, filed 17 Dec. 2008, Attorney Docket No. TN496A; U.S. patent application Ser. No. 12/336,564, entitled “Storage Security Using Cryptographic Splitting”, filed 17 Dec. 2008, Attorney Docket No. TN496B; and U.S. patent application Ser. No. 12/336,568, entitled “Storage Security Using Cryptographic Splitting”, filed 17 Dec. 2008, Attorney Docket No. TN504A. 8. U.S. patent application Ser. No. 12/342,636 entitled “Storage Communities Of Interest Using Cryptographic Splitting”, filed 23 Dec. 2008, Attorney Docket No. TN498. U.S. patent application Ser. No. 12/342,575, entitled “Storage Communities Of Interest Using Cryptographic Splitting”, filed 23 Dec. 2008, Attorney Docket No. TN498A, U.S. patent application Ser. No. 12/342,610, entitled “Storage Communities Of Interest Using Cryptographic Splitting”, filed 23 Dec. 2008, Attorney Docket No. TN498B. 9. U.S. patent application Ser. No. 12/342,379, entitled “Secure Network Attached Storage Device Using Cryptographic Splitting”, filed 23 Dec. 2008, Attorney Docket No. TN499. 10. U.S. patent application Ser. No. 13/493,023, entitled “Software Handling Of Hardware Error Handling In Hypervisor-Based Systems”, filed 5 Sep. 2012, Attorney Docket No. TN550. 11. U.S. patent application Ser. No. 13/547,148, entitled “Automated Provisioning of Virtual Machines”, filed 12 Jul. 2012, Attorney Docket No. TN565. The disclosures of each of these applications are hereby incorporated by reference in its entirety as if set forth in this application.
| Number | Date | Country | |
|---|---|---|---|
| 62018802 | Jun 2014 | US |
