Network Zone Planning For XDM Installations

Planning where to place XDM in your enterprise network is an important step before deployment. This section explains common network zones in typical enterprise environments and discusses different placement options for productive and non‑productive XDM instances. It also shows how XDM communicates with application and database servers across these zones.

Typical Enterprise Network Zones

Many enterprises separate their infrastructure into multiple network zones using firewalls and routing rules. The exact naming and structure differ between organizations, but the following zones are common:

Client Zone

Zone where end users work. Typical systems are user desktops, laptops, virtual desktops, and jump hosts from which users access web applications and administration tools.

Productive Server Zone

Zone where productive application servers and databases are hosted. This zone usually contains the production instances of business applications and their production databases. Access is strictly controlled and monitored.

Test / QA Server Zone

Zone for non‑productive systems such as integration, test, QA, and pre‑production environments. These systems use non‑productive databases and are typically isolated from production systems.

Admin Zone (optional)

Dedicated zone for administrative tools, management systems, monitoring, and central services used by operations teams. In some environments, XDM is placed in this zone to centralize administration.

In all cases, communication between these zones is controlled by firewalls and network policies. This has direct impact on how XDM can access source and target systems.

The following diagram illustrates a typical high‑level separation of zones:

flowchart LR subgraph ClientZone["Client Zone"] C1[User Browser / Admin Workstation] end subgraph AdminZone["Admin Zone (optional)"] A1[Admin Tools] end subgraph ProdZone["Productive Server Zone"] PApp[Prod Application Servers] PDB[(Prod Databases)] end subgraph TestZone["Test / QA Server Zone"] TApp[Test / QA Application Servers] TDB[(Test / QA Databases)] end C1 <-- HTTP(S) --> A1 A1 <-- Admin Protocols --> PApp A1 <-- Admin Protocols --> TApp PApp <-- JDBC / Native --> PDB TApp <-- JDBC / Native --> TDB

Core Characteristics Of Test Data Management Tools

By design, a test data management (TDM) product like XDM must work across zones:

  • It typically reads data from productive systems (production databases in the productive server zone).

  • It writes data into non‑productive systems (test, QA, development databases in the test server zone).

  • It may also write into productive systems when a "golden copy" or pre‑production environment is located there.

This cross‑zone behavior is essential for providing realistic test data: Productive data structures and contents are used as a basis, then copied, subsetted, masked, or transformed before they are written into non‑productive environments.

From a network perspective, the main communication patterns are:

  • HTTP(S) from the Client Zone to the XDM web UI and REST API.

  • JDBC (and, where applicable, native database utilities) from XDM to target databases.

  • Optional HTTP(S) or other protocols from XDM to application servers or external services (for hooks, REST calls, or monitoring).

When planning your deployment, you must ensure that these connections are possible where needed, but also restricted where not allowed by your security policies.

Productive XDM Instance In Productive Or Admin Zone

A productive XDM installation should usually be placed either in the productive server zone or in the admin zone.

  • If XDM is installed in the productive server zone:

    • It is close to the productive databases with low latency.

    • It typically connects directly to productive and non‑productive databases via JDBC and database‑specific utilities.

  • If XDM is installed in the admin zone:

    • It is separated from application servers but can still reach productive and non‑productive databases through controlled firewall rules.

    • Operations teams can manage XDM together with other central tools.

In both cases, the typical communication paths are:

  • End users access XDM from the client zone via HTTP(S).

  • XDM reads from productive databases in the productive server zone.

  • XDM writes into non‑productive databases in the test server zone.

This reflects the core TDM requirement: XDM deliberately works across zones.

flowchart LR %% Zones subgraph ClientZone["Client Zone"] U1["Browser\n(XDM UI)"] end subgraph AdminOrProdZone["Admin Zone or Productive Server Zone"] XDM[Productive XDM Instance] end subgraph ProdZone["Productive Server Zone"] PDB1[(Prod DB 1)] PDB2[(Prod DB 2)] end subgraph TestZone["Test / QA Server Zone"] TDB1[(Test DB 1)] TDB2[(Test DB 2)] end %% Flows U1 <-- HTTP(S) --> XDM XDM <-- "JDBC / Native (read)" --> PDB1 XDM <-- "JDBC / Native (read)" --> PDB2 XDM <-- "JDBC / Native (write)" --> TDB1 XDM <-- "JDBC / Native (write)" --> TDB2

In this setup:

  • The firewall between the client zone and the admin/productive zone must allow HTTP(S) from browsers to the XDM UI. Alternatively, a reverse proxy can be used to forward requests from the client zone to XDM.

  • The firewall between the XDM zone and the productive server zone must allow JDBC and, optionally, native utility connections for reading from production databases.

  • The firewall between the XDM zone and the test server zone must allow JDBC and native utility connections for writing to non‑productive databases.

Non-Productive XDM Instances In Test Zones

In addition to the productive XDM instance, many organizations operate one or more non‑productive XDM instances for development, configuration, and training. These instances are often installed directly in the test server zone.

Typical characteristics of an XDM instance in the test server zone:

  • It is used to develop and test new XDM configurations (tasks, workflows, masking rules, application models).

  • It connects only to non‑productive databases and application servers.

  • By default, it should never be able to connect to production systems. Firewalls and routing should block any access from the test zone to the productive server zone.

With this setup, only test‑to‑test or QA‑to‑QA copies are possible. This is sufficient for many use cases, such as:

  • Testing new task definitions and workflows.

  • Practicing configuration as code deployments.

  • Training new users on XDM without any risk for production data.

flowchart LR %% Zones subgraph ClientZone["Client Zone"] U2["Browser\n(XDM UI - Test)"] end subgraph TestZone["Test / QA Server Zone"] XDMTest[Non-Productive XDM Instance] TApp[Test / QA Applications] TDB[(Test / QA Databases)] end subgraph ProdZone["Productive Server Zone"] PDB[(Prod Databases)] end %% Flows U2 <-- HTTP(S) --> XDMTest XDMTest <-- JDBC / Native (read/write) --> TDB XDMTest <-- HTTP(S) or other --> TApp %% Blocked path XDMTest -.-x PDB classDef blocked stroke:#ff0000,stroke-width:2px,stroke-dasharray:5 5; class XDMTest,PDB blocked;

The dashed red line illustrates that connections from the test XDM instance to productive databases are blocked by design.

Using A Test Or Development XDM Instance In Productive Or Admin Zone

In some organizations, the possibilities of a test‑zone‑only XDM instance are not sufficient. Typical reasons include:

  • Developers or test data engineers need to test TDM workflows using real productive schemas and data volumes.

  • Configuration changes must be validated against the current production structures before rollout.

  • Performance or capacity planning requires realistic measurements using production‑like workloads and data.

In these situations, you can place a test or development XDM instance in the productive server zone or in the admin zone instead of the test server zone.

Important aspects of this setup:

  • The dev/test XDM instance can read from productive databases, similar to the productive XDM instance.

  • It still writes only into non‑productive databases (test, QA, pre‑production).

  • Strong security controls are required:

    • Separate credentials for productive read access with minimal required privileges.

    • Masking and anonymization must be configured to prevent unmodified production data from being written to non‑productive systems where this is not permitted.

    • Clear separation between productive and non‑productive XDM instances (different URLs, roles, and responsibilities).

flowchart LR subgraph ClientZone["Client Zone"] U3["Browser\n(XDM UI - Dev/Test)"] end subgraph AdminOrProdZone["Admin Zone or Productive Server Zone"] XDMDev[Test / Dev XDM Instance] end subgraph ProdZone["Productive Server Zone"] PDB3[(Prod Databases)] end subgraph TestZone["Test / QA Server Zone"] TDB3[(Test / QA Databases)] end U3 <-- HTTP(S) --> XDMDev XDMDev <-- JDBC / Native (read) --> PDB3 XDMDev <-- JDBC / Native (write) --> TDB3

This placement combines the flexibility of accessing production schemas with the safety of writing only to non‑productive targets. However, it must be coordinated with your security, compliance, and data protection teams.

Maintenance And Deployment XDM Instance

When using configuration as code and automated deployments, it can be helpful to run an additional maintenance or deployment XDM instance in the test server zone.

Typical use cases for a maintenance instance:

  • Test and validate configuration imports before applying them to the productive XDM instance.

  • Execute automated deployment pipelines that update XDM configuration from version control.

  • Run regression tests for new XDM versions or container images using only non‑productive systems.

In many setups, this maintenance XDM instance:

  • Runs in the test server zone.

  • Connects only to non‑productive databases and application servers.

  • Is accessed mainly by technical staff (operations, DevOps, test data engineers) from the client zone.

flowchart LR subgraph ClientZone["Client Zone"] Ops[Ops / DevOps Workstations] end subgraph TestZone["Test / QA Server Zone"] XDMMaint[Maintenance / Deployment XDM Instance] TDBM[(Test / QA Databases)] end Ops <-- HTTP(S) --> XDMMaint XDMMaint <-- JDBC / Native (read/write) --> TDBM

This pattern keeps deployment automation and maintenance activities strictly within the non‑productive part of your infrastructure.

Firewall And Network Rules

Firewalls and network policies enforce which connections between zones are allowed. For XDM, a clear and minimal set of rules helps to keep the system secure while still enabling all required data flows.

General Principles

When defining firewall rules for XDM, consider the following principles:

  • Least privilege: Only open ports that are required, in the directions that are required.

  • Zone separation: Do not allow direct access from the test server zone to the productive server zone, except where explicitly needed (for example, read‑only access from a productive/admin XDM instance).

  • One‑way flows where possible: Prefer one‑directional rules (client → server) instead of bidirectional access, especially for database and admin connections.

  • Central access point: XDM’s web UI is typically the only component directly accessed from the client zone. All other services run inside the server zones or Kubernetes cluster.

Client Zone To XDM

From the Client Zone to the Admin Zone or Productive Server Zone where XDM UI runs:

  • Allow HTTP or HTTPS from user browsers to the XDM UI:

    • Protocol: TCP

    • Port: the external HTTP or HTTPS port you configured for the UI (for example 4280, or 443 behind a reverse proxy).

    • Direction: Client Zone → XDM UI host

If a reverse proxy is used (for example Nginx in a DMZ), also ensure:

  • Firewall rules from the reverse proxy to the XDM UI container/service.

  • Correct forwarding of headers and context path so that internal links work as expected.

XDM To Productive Databases

From the Admin Zone or Productive Server Zone (where productive XDM or a dev/test instance is placed) to the Productive Server Zone databases:

  • Allow JDBC and, if required, native utilities from XDM services to production databases:

    • Protocol: TCP

    • Port: database‑specific (for example 5432 for PostgreSQL, 1521 for Oracle, 1433 for SQL Server, Db2 ports as defined by your DBAs).

    • Direction: XDM host(s) → Prod DB host(s)

XDM may establish those connections from these services: * Core Service (JDBC connections to all databases) * Dataflow Service (JDBC connections to all databases) * Task Runner Pods

For security:

  • Use dedicated database users with limited privileges (read‑only where possible).

  • Do not expose database ports to the client zone.

In environments with strict separation, consider using bastion or proxy services (for example, SSH tunnels or cloud SQL proxies) and open the firewall only towards these intermediaries.

XDM To Test And QA Databases

From the Admin Zone or Productive Server Zone (where productive XDM runs) and from the Test Server Zone (where test/maintenance XDM runs) to Test / QA Server Zone databases:

  • Allow JDBC and native utilities from XDM services to non‑productive databases:

    • Protocol: TCP

    • Port: database‑specific (similar to production).

    • Direction: XDM host(s) → Test/QA DB host(s)

Even for non‑productive databases, you should:

  • Restrict access to the exact database servers and ports used by XDM.

  • Separate credentials for test and QA systems from production credentials.

Test Zone To Productive Zone

For XDM instances running inside the Test / QA Server Zone, a common requirement is:

  • No direct connectivity to Productive Server Zone systems.

To enforce this, ensure:

  • No firewall rules from test XDM hosts or Kubernetes namespaces to production database hosts.

  • No routing between test and productive subnets, except potentially via strictly controlled, read‑only services you explicitly decide to allow (for example, central logs or metrics).

This ensures that a test XDM instance cannot accidentally read from or write to production systems.

Reverse Proxies And Context Paths

In some environments, XDM is served behind a reverse proxy with a context path (for example /xdm/).

In this case:

  • Firewalls must allow:

    • Client Zone → Reverse Proxy (external URL, usually HTTPS/443)

    • Reverse Proxy → XDM UI (internal HTTP/HTTPS port, for example 8888 or 4280)

  • The proxy configuration must properly forward:

    • Path and context (/xdm/)

    • Host and X-Forwarded-* headers

    • HTTPS information (X-Forwarded-Proto, etc.)

Misconfigured proxies can lead to broken internal links or non‑working dashboards (for example, missing CSRF headers or incorrect report URLs).

Summary And Recommendations

When planning XDM in your network zones, consider the following guidelines:

  • A productive XDM instance should be placed in the productive server zone or admin zone. It must be able to read from productive databases and write to non‑productive databases.

  • A non‑productive XDM instance in the test zone is ideal for:

    • developing and testing XDM configuration,

    • training users,

    • running deployment tests, without any risk of accessing production systems.

  • If you require realistic tests against production schemas and data, consider an additional test or development XDM instance in the productive or admin zone. Limit its capabilities through strict firewall rules, credentials, and masking rules.

  • A separate maintenance or deployment XDM instance in the test zone can simplify configuration as code workflows and automated deployments.

  • Define a port and firewall matrix that clearly documents:

    • Which component in which zone must talk to which other component.

    • Which protocol and port is used.

    • In which direction the connection is established.

Always coordinate network zone design and firewall rules with your security and compliance teams. Ensure that firewall rules allow the necessary HTTP(S) and JDBC/native database connections, but also enforce the principle of least privilege, especially for access to productive systems.