The modern cyber threat landscape shows a shift in attacker focus from direct corporate perimeter breaches to the compromise of adjacent links. According to the ENISA Threat Landscape 2025 report, essential entities subject to the European NIS2 directive account for 53.7% of all recorded security incidents. In this context, integration nodes have become a primary vector for supply chain attacks, necessitating a transition from fragmented protection to centralized control.
The problem is exacerbated by organizations often relying on fragmented security settings across individual systems. Most integrations were historically built on a point-to-point basis, leading to chaotic architecture. The lack of a single control center creates blind spots and inconsistent access policies, allowing attackers to perform lateral movement between integrated systems.
Anatomy of a threat: why integration nodes are targets
In classic architecture, integration nodes are often viewed merely as a technical layer for data transport. This creates critical vulnerabilities. Consider three typical incident scenarios that arise due to the lack of centralized control:
- Excessive service account privileges. A partner's service account gains access to sensitive data through an integration node because access control lists (ACLs) were not verified at the middleware level.
- Lateral movement due to lack of validation. A compromised partner system injects a malicious payload into the enterprise's internal ERP system. This is made possible by the absence of strict schema validation at the integration gateway.
- Inability to conduct investigations. Following an incident, the security team cannot reconstruct events because logs were scattered across different systems rather than aggregated on a centralized integration hub as an immutable audit log.
NIS2 requirements for integration security: from perimeter to zero trust
The NIS2 directive requires critical infrastructure enterprises to control the security of the entire supply chain. This means transitioning to a Zero Trust model, where managed Enterprise Integration Patterns are used instead of chaotic point-to-point connections. All integration flows must pass through a centralized layer—managed message buses or an API Gateway.
Using an API Gateway creates a single point for authentication, rate limiting, and traffic observability. To ensure consistent enforcement of security policies, integration nodes must process a significant portion of inter-system traffic.
Architectural pattern for a secure node: RBAC, RLS, and schema validation
To build an integration node, a three-tier protection system must be implemented directly at the middleware level:
Role-based access control (RBAC)
Strict RBAC is implemented at the integration gateway level. Instead of general access, partner systems are restricted to only those API methods necessary for their functions, which minimizes service account privileges.
Row-level security (RLS)
The Row-Level Security (RLS) mechanism provides dynamic data filtering. Even with access to a specific API method, the partner system receives only the records belonging to it. This prevents horizontal privilege escalation and unauthorized access to third-party data.
Strict data validation
The integration gateway must perform mandatory validation of incoming messages against defined JSON/XML schemas before forwarding the request to internal systems. Any deviation from the structure results in the request being rejected. Furthermore, the latency for security policy checks (RBAC/ACL) must be kept within low-millisecond ranges to avoid performance degradation in high-load scenarios.
Audit and investigation: immutable audit trail
NIS2 requirements for rapid incident detection and reporting necessitate comprehensive retrospective analysis tools. Event streaming platforms, such as Apache Kafka, allow for the implementation of an immutable audit trail.
Each transaction is recorded as an event, enabling event replay—a critical function for investigating complex incidents and restoring the system state at the time of an attack. To avoid performance degradation, such auditing should be performed asynchronously.
Implementing NIS2 requirements on the UnityBase platform
Building secure integration nodes requires a reliable technological foundation. The UnityBase platform, a joint development of the Intecracy Group alliance (where InBase is a key developer), provides the necessary mechanisms. Installing the platform does not automatically grant NIS2 compliance certification, but it provides architects with the technical tools that, when properly configured, satisfy the directive's requirements.
- Centralized domain model. Using domain metadata automatically generates REST APIs and allows security and validation rules to be described in a single location.
- Built-in RBAC and RLS. The platform natively supports role-based access and row-level security, flexibly restricting partner systems.
- Immutable audit. DataHistory and secure Audit Trail mechanisms automatically record transaction history without impacting API processing speed.
According to official developer recommendations, commercial editions—Enterprise (EE) and Defence (DE)—are used for critical infrastructure and high-load systems. The Enterprise edition expands capabilities through ACLs, attribute-level security, support for Oracle and MySQL, and integration with Active Directory and OpenID Connect/OAuth2. The Defence edition adds strict authorization via private/public keys, device fingerprinting, and integration with certificate authorities (CRL, OCSP).
The UnityBase platform successfully functions as an integration layer, allowing legacy systems and modern services to be combined into a secure perimeter. It is on these mechanisms that document-oriented enterprise solutions such as Megapolis.DocNet and Scriptum.DMS are built, demonstrating the ability to withstand high loads while strictly adhering to security policies.
| Compliance criterion | NIS2 requirement | Technical implementation at the gateway level |
|---|---|---|
| Access control | Restricting partner access rights. | Implementation of RBAC and Row-Level Security (RLS), minimization of service account privileges. |
| Data validation | Prevention of injections. | Mandatory verification of incoming messages against JSON/XML schemas. |
| Audit (Audit Trail) | Rapid detection and reporting. | Centralized immutable audit log, event replay capability. |
| Performance | Business process continuity. | Policy check latency within the low-millisecond range. |
FAQ
How to ensure NIS2 supply chain security compliance without rewriting legacy system code?
The optimal path is implementing a centralized integration layer (API Gateway or platforms like UnityBase). All security checks, including authentication, schema validation, and RBAC/RLS enforcement, are performed at this intermediate level before the request reaches the legacy system.
What is the difference between RBAC and RLS when configuring access rights for external integrations?
RBAC (Role-Based Access Control) determines whether an external system has the right to call a specific API method. RLS (Row-Level Security) filters data at the database row level, ensuring that within a permitted API method, the partner only accesses their own records.
How to organize transaction auditing in integration nodes so that logging does not reduce system performance?
To ensure low-millisecond latency, logging must be performed asynchronously. Using event-driven platforms (like Apache Kafka) or audit modules optimized for high loads allows for recording the Audit Trail in the background without blocking main traffic processing.