1.1. Scenario:

KATA/EDR CN is deployed on site, and there are some remote users that cannot connect to the internal network, and you want to receive the EDR telemetry from those endpoints and laptops when they are outside the network (considering that you don't have any VPN functionality).

You don't want to expose the CN on the internet, so you'd like to use the sensor to relay the telemetry to the CN and have visibility on the endpoints.

1.2. Warning

Sensor that is published (port 443 TCP) to wild internet for endpoint agent integration will not be a reason for denial of technical support.

We regularly close known vulnerabilities (including those reported by customers) with private fixes and workarounds.

However, for this functionality you must consider that KATA EDR allows SoC users (security officers) to execute arbitrary code on workstations with agents deployed.
Such capability is also present for example in KSC <-> Network Agent. But in KSC <-> Network Agent it is recommended to publish only a connection gateway, in which case connection gateway can be automatically updated via bases with fixes for SSL vulnerabilities.
Currently there is no such functionality with automatic fixes installation for SSL vulnerabilities via bases updates in KATA Sensor.
Also KATA EDR stores and processes much deeper data than KSC. 

Considering above the following is recommended:

1) Allocate a dedicated and isolated central node which would not process data from corporate network where data has a different class of confidentiality. 
Meaning that even if you publish only a sensor, it is not recommended to connect that sensor to the same central node that processes agents installed on domain controllers.

2) Published sensor should not process any data from corporate network. For example, no SPAN or other integrations from corporate network, no agents connecting from inside corporate network.

3) Configure telemetry storage in such way so that only several days of telemetry is stored on central node to which published sensor is connected.

4) If possible limit IP range from where published port is accessible. For example, using some geoip database.

5) Enable validation of client certificate: https://support.kaspersky.com/help/KATA/7.1/en-US/247876.htm .

1.3. Pre-requisites and configuration steps:

To achieve the above scenario, we can deploy the KATA Network Sensor in the DMZ and publish it on the internet for remote and roaming users. The Network Sensor will be integrated with the CN and public IP/FQDN will be used to send the traffic from the internet to the sensor using port 443.

Two KES policies (Active/Out of Office) will be configured, The Active policy will have the KATA CN internal IP and the Out-of-Office policy will have the public IP/FQDN for KATA Sensor.

Connection profiling can be used to switch between the policies (similar to the connection gateway for KSC).

The below steps need to be performed for the successful deployment and integration.

• Deploy the KATA Network Sensor in the DMZ
• Configure to integrate with CN, and accept the request on the CN side.
  1. When using the KEDR license, the Accept button might not be available, integration of the KATA sensor requires a KATA license, or the latest KATA patch should be applied on the CN to fix this issue.
• Export the certificate from the KATA Sensor using WinScp and copy it to the local computer or KSC server.

Note: you might need to allow the connection using WinSCP:

https://forum.kaspersky.com/blogs/entry/100-how-to-copy-files-tofrom-kata-katakedre/

Copy the kata-current.crt with WinSCP.

• Apply the KES (Out-of-office) policy to a test laptop.
• Disconnect the Laptop from the network and wait for the connection to be established from the internet with KATA Sensor.
• Verify the Endpoint status on the Central Node and check for the recent events.