DC CORE
Access private applications without exposing the host.
Give authorised users access to an internal application without directly publishing its underlying server. Start with the service people need, its local address and the users allowed to reach it.
Plan access to one private application.
Consider an internal administration website on a server at your office. Staff working elsewhere need that website, but do not need general access to every device on the office network.
| Question | Example decision |
|---|---|
| What must be reachable? | The administration website and its required local service port. |
| Where does it run? | A private server address reachable from the approved agent location. |
| Who needs access? | Named staff with the appropriate application and Central permissions. |
| Which path fits? | Authorised service publishing or an endpoint-to-endpoint private connection, according to the confidentiality requirement. |
Check the service and the access boundary.
- Verify that the application works from its local network and has the intended authentication.
- Prepare the agent and outbound access using the setup information in Central.
- Configure the approved service path and restrict it to the required users or systems.
- Test from a remote location and verify that an unauthorised user cannot access the protected service.
The target host does not normally need a public inbound management port for supported agent paths. Its local firewall, application permissions and endpoint controls still apply. Publishing a service through secured ingress is different from encrypting its payload end to end.
Review the security boundaries · Understand access behind NAT
Connect your application through Central.
Standard Central connectivity is included with Central plans. High-volume continuous transfer and specialist requirements may need separate pricing. See prices and inclusions.