When a cloud-based platform needs to access data on a server within the corporate network, the first solution that comes to mind is opening an external port. This rightfully causes concern on the IT side.
Every opened port means a door for external connections and must be continuously protected. Most businesses do not want to take this risk, and integration projects stall at this point.
In this article, we explained the agent model, connection direction, queue structure, and monitoring methods that eliminate this problem.
Table of Contents
What is an agent?
An agent is a small connection component installed on a machine within the corporate network. Its job is to bridge the local system and the cloud platform.
This component does not act as a server and does not listen for incoming connections from the outside. It only initiates connections itself and exchanges data.
On the local side, it accesses the database or application interface and reads the necessary data. Similarly, it writes records coming from the cloud to the local system.
Resource consumption is low, and it can usually be run on an existing server. A separate hardware requirement does not arise in most installations.
This model is a common and accepted method of combining local systems with cloud platforms.
Why is connection direction important?
What is decisive from a security perspective is the direction in which the connection is established. This detail changes the entire risk profile.
A connection established from the outside in requires opening a door in the firewall. This door is also open to malicious access attempts.
A connection established from the inside out uses the existing internet egress. No new door is opened, and the attack surface does not grow.
The agent model uses precisely this second approach and always initiates the connection itself.
Therefore, its acceptance on the IT side is much easier compared to classical methods.
How does it work?
Once installed, the agent connects to the cloud platform and establishes a continuously open channel. Two-way communication is provided through this channel.
When the platform sends a data request, the agent executes this request on the local system and transmits the result back.
Changes occurring in the local system are also detected by the agent and sent to the platform. The detection method varies depending on the structure of the system.
The transferred data is converted according to defined mapping rules. This transformation is usually done on the cloud side.
When the process is complete, the result is recorded, and if there is an error, it falls into the list.
Queue management
The connection may not always remain open, and in this case, data must not be lost. The queue structure provides this guarantee.
Unsent records are kept in the queue and transmitted in order when the connection is restored. Thus, an interruption does not turn into data loss.
Maintaining the sequence is important; processing documents in a different order can produce inconsistencies.
The number of retries must also be limited. Infinite retries hide a real error forever.
Records that fail after a certain number of attempts should be added to the error list and investigated.
Security model
Security in agent installation is not limited to just the connection direction and consists of several layers.
Data transfer must be done over an encrypted channel; unencrypted transfer is unacceptable.
The agent's access privileges in the local system should also be kept limited. It is sufficient to access only the tables it needs.
Authentication credentials must be stored securely and not kept as plain text.
It is also necessary to record the operations performed; audit logs you can check out the article.
Installation requirements
Agent installation does not require complex infrastructure preparation and is usually completed in a short time.
A machine that remains continuously open is required; an agent running on a shut-down computer stops synchronization.
Internet access must be available; however, this access may be limited and restricted only to necessary addresses.
A user account must be defined for access to the local system. This account should only have the necessary privileges.
A connection test must be performed after installation and verified with a data read attempt.
Monitoring and alerts
Monitoring whether the agent is running is critical for the reliability of the integration.
The connection status must be continuously visible; if an interruption goes unnoticed, data will accumulate.
An alert must be generated when a connection cannot be established for a certain period. This alert needs to reach the IT administrator.
Queue length must also be monitored; a growing queue indicates a problem with the transfer.
The last successful sync time is the most practical indicator and summarizes the status at a single glance.
Outage scenarios
Outages are inevitable, and what matters is how the system responds to them.
During an internet outage, the agent attempts to re-establish the connection and records wait in the queue.
When the local system is under maintenance, read operations fail and this situation is logged.
When the server is restarted, the agent must be ensured to start automatically.
During long outages, processing accumulated records takes time; this duration must be taken into account during planning.
Maintenance and updates
The agent is not a component to be installed and forgotten; it requires periodic maintenance.
Updates need to be planned; during the update, synchronization pauses briefly.
Version changes in the local system can also affect the agent side. Such changes must be notified in advance.
The location where log files accumulate should also be checked; a full disk can stop synchronization.
In the event of a server change, the agent must be reinstalled and the connection verified.
Points to consider
Running the agent on a shut-down machine is the most common operational issue.
Granting overly broad access permissions also creates unnecessary risk.
When monitoring is not set up, outages are noticed late and data accumulates.
Failure to involve the IT team in the process leads to later objections; information must be provided prior to installation.
Scope and requirements must be clarified together before installation; system synchronization plan is made accordingly.
Frequently asked questions
Is it necessary to open a port on the firewall?
Not necessary; the connection is established from the inside out and the existing internet output is used.
Is a separate server required?
Usually not required; an existing machine that stays on continuously is sufficient.
Is data lost when the connection drops?
It is not lost; records wait in the queue and are transmitted sequentially when the connection is restored.
Can multiple systems be connected?
It depends on the setup; we evaluate your needs together during the installation phase.
The agent model is both a secure and practical way to combine local systems with cloud platforms. It also eliminates the biggest objection on the IT side right from the start.
Clearly explain to your team that the connection is established from the inside out; the concern of opening ports is the most frequent stumbling block in projects.
Run the agent on a machine that stays on continuously; a shut-down computer is the most common operational issue.
Set up the monitoring and alerting structure from the start as well; an unnoticed outage turns into a major data gap days later.
Keep access permissions restricted as well; the agent should only access the data it needs.
By consulting with the EQLEM team, you can plan your connection architecture.