Integration Security – Has Your Integration Already Been Hacked?

Integration security is not a technical detail – it is a business risk. Insecure integrations are among the most common causes of data breaches, system outages, and compliance violations. The resulting financial, legal, and reputational damage can be substantial.

Regulations such as GDPR, NIS 2, and ISO 27001 clearly state that organizations are responsible for securing their integrations, even though they rarely prescribe concrete technical solutions. Architecture, development, and operations must translate these requirements into practice.

Modern integration patterns such as pull-only and message-broker architectures significantly reduce attack surfaces, support zero-trust principles, and simplify auditing. Traditional VPN or reverse-proxy approaches can still be useful in specific scenarios but should no longer serve as the primary security mechanism.

Investing in integration security delivers measurable value: it reduces incident risk, simplifies audits, lowers operational effort, and protects the organization’s reputation.

This article focuses on security in data integration, covering data flows, systems, interfaces, and architectures. It addresses legal requirements and, above all, practical technical measures. 

Legal Frameworks for Integration Security

GDPR

GDPR applies whenever personal data is processed. Its principles include data minimization, purpose limitation, transparency, and security.

For developers, this means:

• No unencrypted transmission of personal data
• Encryption and pseudonymization in transit and at rest
• Careful logging that avoids unnecessary personal data

NIS 2

NIS 2 expands cybersecurity requirements to many more organizations. It focuses on risk management, incident response, and supply chain security.

For developers, this means in their day-to-day work:

• Secure hybrid cloud/on-premises integrations
• Monitoring, secure communication, and IDS/IPS
• Assessment of third-party libraries and connectors

ISO 27001

ISO 27001 defines an Information Security Management System. It requires structured risk management, documentation, and auditability.

Practically relevant for developers:

• Documented encryption and access controls
• Defined patching and incident processes
• Auditable implementations

German Implementation (BSIG / NIS2UmsG)

German regulations require “state-of-the-art” security measures, especially for critical systems, including strong authentication, monitoring, and traceability.

Overall, regulations define *what* must be achieved, not *how*. Developers and architects are responsible for implementing secure solutions.

From Rules to Reality

The regulations described above rarely tell us in detail how to implement something – but they are very clear that we have to do it. And this is exactly where we as developers come in: we build the “how” with secure APIs, encryption, clean logging, zero-trust principles, and the right architectures.

In this section, we’ll take a look at what this means from a technical perspective and how these requirements can be implemented in a practical and sensible way.

Defense in Depth

Defense in depth combines multiple independent security layers. Firewalls, authentication, encryption, monitoring, and segmentation complement each other. If one layer fails, others still provide protection.

Security emerges from coordinated controls, not from single tools.

Deliberately Excluded Topics

Some aspects of data integration architecture, such as cloud vs. on-premises or data residency, are often predefined by compliance requirements. The core security principles apply regardless of these constraints.

Data Protection

Security starts with data. Sensitive information should be pseudonymized, especially in development environments. Encryption must be applied both at rest and in transit.

Statements like “TLS is unnecessary in internal networks” underestimate insider risks and lateral movement by attackers. Internal communication must also be encrypted.

Advanced approaches such as confidential computing can further limit data exposure, although they are not yet widely supported in integration platforms.

Backups

Secure backups enable recovery from ransomware or data loss. They must also be encrypted and protected.

Runtime and Development Security

Platform Operations

Many incidents originate from vulnerable libraries and frameworks. Regular patching and updates are essential.

Secure Development Practices

Effective security begins in development. Key practices include:

• No secrets in code repositories
• Strict input validation
• Protection against SQL and script injection
• Mitigation of prompt injection
• Robust error handling
• Proper timeout handling
• Idempotent processing
• Dead-letter queues
• Rate limiting and throttling

Logging and Monitoring

Logging

Logging supports troubleshooting and auditing. However, excessive logging of sensitive data undermines security. Logs must be informative but privacy-conscious.

Passwords, tokens, and personal data do not belong in log files.

Monitoring

Monitoring systems analyze log data to detect anomalies and trigger alerts. While mainly reactive, they are essential for early detection and incident response.

Authentication and Authorization

Security applies to both human users and system communication.

Organizationally, access follows least-privilege and need-to-know principles. Permissions must be regularly reviewed and revoked when no longer required.

Technically, integrations rely on machine identities, certificates, and OAuth 2. Credentials must be managed throughout their lifecycle.

Strong user security is ineffective if technical communication is weak, and vice versa.

Network Security

Network security aims to minimize attack surfaces and detect suspicious activity.

Core measures include:

• Closing unnecessary ports and services
• Segmentation and firewall rules
• IDS/IPS and WAF systems
• DDoS protection
• Malware detection
• Security event logging

Network security is a continuous process that requires regular reviews and vulnerability management.

Risk Management and Incident Handling

Risk management means identifying relevant threats, assessing their impact, and reviewing them regularly. Integration landscapes evolve, and so do risks.

Incident handling requires defined responsibilities, procedures, and tools. Effective logging, monitoring, and access controls are crucial during incidents. The goal is not to eliminate all risks, but to be prepared.

Integration Architectures

Two modern patterns are considered state of the art: pull-only and message-broker architectures. VPN and reverse-proxy approaches remain usable but should no longer be primary security mechanisms.

Fundamental Integration Principles

Regardless of architecture:

• Network segmentation
• No open inbound access
• Minimal attack surface
• Encrypted communication
• Machine-based authentication
• Least privilege

Technical Minimum Measures

• TLS 1.2/1.3
• Certificate-based authentication
• Token rotation
• Machine identities
• Payload validation
• Logging and monitoring

Pull-Only Architecture

Concept

All connections are initiated from inside the internal network. External systems only provide data. Typical implementations use HTTPS polling.

Advantages

• No inbound ports
• Small attack surface
• High auditability
• Clear communication paths

Measures

• TLS and mTLS or OAuth 2
• API gateways
• Rate limiting
• Schema validation

Assessment

Pull-only architectures are highly secure and favored by regulators. They align well with zero-trust principles.

Message Broker Architecture

Concept

Producers publish messages to a broker. Consumers retrieve them asynchronously. No direct cloud-to-intranet connection exists.

Advantages

• Clear separation of systems
• Fine-grained access control
• High scalability
• Strong traceability

Measures

• Private endpoints
• TLS and certificates
• IAM/ACL policies
• Dead-letter queues
• Optional message signing

Assessment

Message brokers provide robust, scalable, and auditable integration patterns, especially for large environments.

VPN Architecture

Concept

A site-to-site VPN connects cloud and internal networks, making them appear as one environment.

Measures

• Secure VPN protocols
• Strong segmentation
• DMZs
• IDS/IPS
• Application-level authentication

Risks

• Increased attack surface
• High impact of misconfigurations
• Greater operational effort

Assessment

VPNs are acceptable for legacy scenarios but should not serve as the sole security mechanism.

Reverse Proxy Architecture

Concept

A public endpoint in a DMZ forwards requests to internal systems via a proxy.

Measures

• TLS termination and re-encryption
• mTLS
• IP filtering
• WAF
• Rate limiting

Risks

• Exposed entry point
• High dependency on correct configuration
• Centralized failure risk

Assessment

Reverse proxies require mature operations and should mainly complement other security measures.

Conclusion

Integration security is the result of many coordinated decisions across architecture, development, and operations.

Regulations define the framework, but implementation is the responsibility of developers and architects. Secure identities, encrypted communication, controlled logging, and realistic risk assessments significantly reduce vulnerabilities.

Pull-only and message-broker architectures provide the strongest foundations for modern, secure integrations. VPNs and reverse proxies still have their place but should not dominate security strategies.

Defense in depth connects all layers: data handling, development, runtime, networking, and incident management. No single measure is sufficient, but many aligned measures make a decisive difference.

The goal of integration security is not absolute protection. It is to make attacks unlikely, limit their impact, and ensure preparedness. Achieving this greatly reduces the risk of becoming tomorrow’s headline.