How K2 Cloud Secure Data Access Works
KB002739
PRODUCT
K2 Cloud Secure Data Access (SDA) enables you to access your traditional, on-premises line-of-business systems from K2 Cloud applications without the need to open access within the firewall, place systems outside the firewall, or create VPN connections. Connections to your K2 Cloud tenancy originate from a network appliance deployed within your private network and are secured by an SSL-based, encrypted and exclusive connection between your on-premises environment and your tenancy.
Overview
Traditional approaches to connecting on-premises and cloud platforms require complex VPN structures, expensive dedicated circuits, or solutions that require publicly exposing certain network communication ports. These solutions create larger surface areas for data leakage and security breaches in your organization.
K2 SDA utilizes a patented, reverse-access technology that does not require a VPN, DMZ, publicly-accessible ports or other network infrastructure changes in your on-premises environment.
Accessing On-Premises Systems
K2 SDA provides integration with the following on-premises line-of-business systems compatible with K2 Cloud. For the latest compatibility information, see Product Compatibility, Integration and Support.
- Microsoft SQL Server 2014, 2016, and 2017
- Microsoft Dynamics CRM 2013, 2015, and 2016
- Microsoft Exchange 2013 and 2016
- Oracle 11g (releases 1 & 2) and 12c
- REST web services
- WCF web services
- SOAP web services
- OData web services
You connect your on-premises systems to your K2 Cloud tenancy using a web-based administration portal that is part of the SDA Access Controller (the “controller”). This provides the ability to expose line-of-business systems, configure the ports that traffic flows through, and more.
Deployment
K2 SDA is deployed as a matched pair of nodes: a Controller node, and a Gateway node. You deploy the Controller node in your on-premises environment as a virtual machine hosting the SDA administration site, while the Gateway node is deployed by K2 Operations in your K2 Cloud tenant environment.
Once you pair the nodes, an encrypted and exclusive tunnel is used between the nodes that allow traffic to flow from on-premises systems into your K2 Cloud tenant. The SDA Controller ensures that requests to on-premises systems can only be received and fulfilled by the SDA appliance if that request originated from within the paired node in your K2 Cloud tenant.
| | ||
Gateway (K2 Cloud environment node)Located in the organization’s K2 Cloud tenant, the role of the gateway SDA node is to act as a front-end to all applications and users within K2 Cloud. It operates without the need to open any ports in your firewall and ensures that only legitimate session data can pass through into your internal network. This component runs as a windows service on a K2 Cloud environment. It accepts inbound tcp connections from K2 and queues the requests for access to on-premises LOB systems. | | Controller (On-Premises node)The role of the controller SDA node is to:
If the session is legitimate, the data request is passed to the destination application server for processing and then returns to the K2 Cloud tenant. The SDA Access Controller establishes a persistent outbound tcp connection with the SDA Gateway and pulls the queued requests for access to on-premises LOB systems down, eliminating the need to open incoming ports on the private network firewall. The SDA Access Controller node then brokers the connection to the on premises LOB system and pushes the response back out to the SDA Gateway, then ultimately to the K2 server and end user. The controller is platform-agnostic and supports Windows Server and Linux distributions, and you can deploy it on your network using a virtual server infrastructure. |
Communication Flow Example
The diagram below illustrates how communication is initiated and flows in an SDA implementation. In this example, we are using SQL Server as the on-premises LOB system.
- iK2 Cloud] A user accesses a Smartform in the K2 Cloud environment, and the SmartForm executes a SmartObject configured to return data from the on-premises SQL database.
- sK2 Cloud] The SQL Service Instance is configured to forward the request to the Gateway via the External Bind Port, 1443, where it is queued.
- hPrivate Network] The Access Controller polls the Gateway for new requests via a persistent connection on the Control Port, 808, and pulls the request in.
- lPrivate Network] The Access Controller brokers the request to SQL Server via the Service Port, 1433.
- Private Network] The Access Controller sends the response with the data payload to the Gateway using the Callback Port, 2443.
- K2 Cloud] The Gateway sends the response back to K2 on the tcp connection previously established using the External Bind Port and the response is surfaced in the Smartform to the user.
Security
K2 SDA isolates applications and APIs from external attackers, effectively making internal data invisible on the internet while providing the ability to build K2 Cloud apps to integrate with your on-premises line-of-business systems. To protect your on-premises environment, K2 Cloud SDA provides the following layers of security protection:
- Traffic coming into the on-premises environment from the K2 SDA gateway can only originate from the corresponding paired node
- The external K2 SDA node does not persist or store any data from requests to or from on-premises systems
- Bolsters the protective effect of your corporate firewall by using a patented two-node, reverse-access technology
- Eliminates opening any standard incoming ports on the internal firewall for client requests to reach line-of-business servers
- Provides layer 3/4 (IP/TCP) attack protection
- Provides fine-grained access control and security policies to limit access to line-of-business servers
See Also
For more information about K2 SDA, see Overview, Installation, and Configuration of K2 Cloud Secure Data Access
