ENTERPRISE REFERENZARCHITEKTUR · ZERO-ATTRIBUTION

First-Party Reverse Proxying als Enterprise-Standard

Warum souveräne Finanzinstitute, Kernbanken und Acquirer auf First-Party Ingress setzen: Vollständige Eliminierung von Drittanbieter-Footprints, Schutz vor Wettbewerber-Profiling und latenzfreie In-Flight-Sicherheit direkt im Netzwerkpfad.

⚖️
Historische Klarstellung: Früher evaluierte Verfahren zur clientseitigen Hardware-Attestierung (Halbleiter- / GPU-Profiling) wurden offiziell eingestellt. Der heutige Enterprise-Standard für Sanction Sieve™ und Pattern Sieve™ ist die rein serverseitige In-Flight-Pipeline oder – bei Web-Ingress – das First-Party Reverse Proxying über Ihre eigene Kundendomain.

Warum konventionelle Drittanbieter-CDNs scheitern

Traditionelle Sicherheitsanbieter verlangen von Unternehmen, externe JavaScript-Tags oder Beacons in den Bezahl- und Anmeldeprozess einzubetten. In regulierten Enterprise- und Bankenumgebungen erzeugt dieses Vorgehen gravierende strukturelle Risiken:

Wettbewerber-Profiling

EXPOSURE

Öffentliche Quelltext-Crawler, HTTP-Archive und Tech-Stack-Scanner (z. B. Source-Code-Crawler) erfassen externe Skript-Tags vollautomatisch. Wettbewerber und Marktanalysten können jederzeit exakt nachvollziehen, welche Sicherheits- und Transaktions-Engines in Ihrem System laufen.

  • Vollständige Transparenz Ihrer Sicherheits-Vendoren für Dritte
  • Gezielte Akquise- und Verdrängungsanalysen durch Mitbewerber

Gezielte Angreifer-Bypässe

EXPLOIT

Automatisierte Betrugsnetzwerke und Card-Testing-Cluster scannen nach bekannten Drittanbieter-Hostnames. Sie blockieren diese Endpunkte selektiv via DNS/Adblocker oder konfigurieren Emulatoren, um die externen Bibliotheken zielgerichtet ins Leere laufen zu lassen.

  • Einfache Filterung von Drittanbieter-Beacons durch Botnetze
  • Gefahr von Silent-Failures bei blockierten Fremd-CDNs

DORA Art. 12 & IKT-Drittparteienrisiko

Gemäß DORA (EU-Verordnung 2022/2554) und dem österreichischen Bankgeheimnis (§ 38 BWG) stellen unkontrollierte externe Skript-Abhängigkeiten im Bezahlvorgang ein kritisches Supply-Chain-Risiko dar. Fällt das CDN des Drittanbieters aus oder wird es kompromittiert, drohen Ausfälle des Checkout-Prozesses und Haftungsrisiken.

First-Party Reverse Proxying (Zero-Attribution)

Um vollständige Vertraulichkeit, Unangreifbarkeit und regulatorische Souveränität zu gewährleisten, schreibt GAMPERLAB™ das First-Party Reverse Proxying als Standard-Referenzarchitektur für alle Kundenintegrationen vor:

Endnutzer / Client Browser / Mobile App checkout.ihre-bank.at First-Party HTTPS /api/sec/verify Enterprise Ingress API Gateway / Reverse Proxy (Nginx / Envoy / Cloudflare) ✓ Zero External DNS Footprint ✓ Header Sanitization Dediziertes mTLS VIX Peering GAMPERLAB™ Engine Sovereign Native Engine < 0.26 ms Screening Keine Datenspeicherung

100 % Zero-Attribution

STANDARD

Nach außen hin ist für keinen Beobachter, Crawler oder Wettbewerber ersichtlich, welcher Sicherheits- oder Screening-Dienst aktiv ist. Alle Anfragen fließen originär über Ihre eigene Unternehmensdomain.

  • Keine Vendor-Hostnames im HTTP-Traffic oder HTML-Quelltext
  • Schutz der institutseigenen Technologieentscheidungen

Bypass-Resistenz & DORA-Souveränität

SECURE

Botnetze können die Endpunkte nicht selektiv blockieren, da ein Blockieren der First-Party-Route den gesamten Bezahlprozess abbrechen würde. Das Drittparteienrisiko wird auf eine souveräne Backchannel-Verbindung reduziert.

  • Kein Angriffspunkt für typische Adblock- / DNS-Filterlisten
  • Vollständige Kontrolle über mTLS-Zertifikate und Header-Routing

Referenz-Snippets für Enterprise Ingress

Wählen Sie Ihre bestehende API-Gateway- oder Reverse-Proxy-Infrastruktur. Die Weiterleitung erfolgt transparent unter Ihrer eigenen Domain mit striktem mTLS-Handshake und Header-Sanitization:

nginx.conf — Enterprise First-Party Reverse Proxy
# First-Party Reverse Proxying für Zero-Attribution Ingress
location /api/sec/ {
    # Weiterleitung an den dedizierten, souveränen Screening-Cluster
    proxy_pass https://upstream-internal-cluster:8443/;
    
    # Striktes Mutual TLS (mTLS) zwischen Ihrem Gateway und der Engine
    proxy_ssl_certificate         /etc/ssl/certs/enterprise-client.crt;
    proxy_ssl_certificate_key     /etc/ssl/private/enterprise-client.key;
    proxy_ssl_trusted_certificate /etc/ssl/certs/engine-ca.crt;
    proxy_ssl_verify              on;
    proxy_ssl_protocols           TLSv1.3;
    proxy_ssl_server_name         on;

    # Header-Sanitization: Keine Leaks nach außen, Herkunft intern verifizieren
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Origin-Tenant-Domain $host;

    # Verbergen aller Upstream-Signale vor dem Browser
    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;
    add_header X-Content-Type-Options nosniff always;
}
envoy-filter.yaml — Kubernetes Gateway & Envoy Filter
# Envoy Route Configuration für First-Party Endpoint
routes:
  - match:
      prefix: "/api/sec"
    route:
      cluster: "sovereign_engine_cluster"
      prefix_rewrite: "/v1"
      timeout: 0.5s
    request_headers_to_add:
      - header:
          key: "X-Ingress-Gateway"
          value: "enterprise-core-ingress"
    response_headers_to_remove:
      - "x-envoy-upstream-service-time"
      - "server"

# Upstream mTLS Cluster Definition
clusters:
  - name: "sovereign_engine_cluster"
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        common_tls_context:
          tls_certificates:
            - certificate_chain: { filename: "/etc/ssl/client.crt" }
              private_key: { filename: "/etc/ssl/client.key" }
          validation_context:
            trusted_ca: { filename: "/etc/ssl/engine-ca.crt" }
edge-worker.js — Cloud Edge Ingress Middleware
// Edge Middleware für First-Party Sub-Request Proxying
export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    // Nur First-Party Pfade abfangen
    if (url.pathname.startsWith('/api/sec/')) {
      const backendUrl = 'https://upstream-internal-cluster:8443' + url.pathname.replace('/api/sec', '');
      
      // Neuer Request mit bereinigten Headern
      const proxyReq = new Request(backendUrl, {
        method: request.method,
        headers: request.headers,
        body: request.body
      });
      proxyReq.headers.set('X-Forwarded-Host', url.hostname);
      proxyReq.headers.delete('cf-ray');

      const response = await fetch(proxyReq);
      const cleanRes = new Response(response.body, response);
      cleanRes.headers.delete('server');
      cleanRes.headers.delete('x-powered-by');
      return cleanRes;
    }

    return fetch(request);
  }
};
Caddyfile — Modern Zero-Config Reverse Proxy
# First-Party Endpoint unter der eigenen Domain
checkout.ihre-bank.at {
    handle_path /api/sec/* {
        reverse_proxy https://upstream-internal-cluster:8443 {
            transport http {
                tls
                tls_client_auth /etc/ssl/client.crt /etc/ssl/client.key
                tls_trusted_ca_certs /etc/ssl/engine-ca.crt
            }
            header_up Host {host}
            header_up X-Real-IP {remote_host}
            header_down -Server
        }
    }
}
Sicherheitsprinzip: Alle Upstream-Verbindungen werden über Mutual TLS (mTLS) authentifiziert. Kein Gateway-Proxy exponiert interne Cluster-Adressen an den Client. Der Browser sieht ausschließlich Standard-HTTPS-Routen Ihrer vertrauten Domain.

0,0 % Client-Footprint: Die ideale Enterprise-Architektur

Für Kernbanken, Acquirer und Zahlungsdienstleister (Payment Service Provider) empfiehlt GAMPERLAB™ die vollständige serverseitige In-Flight-Architektur. Bei Sanction Sieve™ und Pattern Sieve™ wird der Datenstrom direkt im Autorisierungs- oder Transaktionspfad geprüft – ohne ein einziges Byte JavaScript im Browser:

Option A: Embedded In-Memory Sidecar

Die Engine läuft als souveräne Native-Engine direkt auf demselben Host oder als Sidecar im Kubernetes-Pod Ihrer Autorisierungs-Instanz.

  • Kommunikation über Unix Domain Socket oder Shared Memory
  • Latenz: < 40 Mikrosekunden (0,04 Millisekunden)
  • Absolut autark ohne externe Netzwerkanbindung

Option B: VIX Glasfaser-Direktanbindung

Für Banken und Acquirer mit Rechenzentren im Raum DACH/CEE: Direkte, private Kopplung am Vienna Internet eXchange (VIX) in Wien über dediziertes Cross-Connect.

  • Dedizierte mTLS-Transit-Leitung am VIX-Knoten
  • Latenz: < 0.26 Millisekunden
  • Kein öffentlicher Internet-Hop, maximale Ausfallsicherheit

Erkennung von Kartentest-Angriffen ohne Frontend-Scripting

Pattern Sieve™ analysiert Transaktionssequenzen portfolioweit über Hunderte Händler hinweg. Professionelle Angreifer, die rotierende Headless-Browser und emulierte Geräte nutzen, können clientseitig jedes Skript fälschen oder blockieren. Die In-Flight-Mustererkennung auf Transaktionsebene setzt dort an, wo der Angreifer den Zahlungsfluss nicht manipulieren kann: direkt an den Autorisierungs-Rails des Acquirers.

Build-Polymorphismus & Standard-Minification

Sollten in spezifischen Web-Portalen oder Formularen clientseitige Validierungen gewünscht sein, gelten strikte Zero-Attribution-Vorgaben für die Bereitstellung:

Die 4 Grundregeln für clientseitige Bundles

1. First-Party Asset Hosting

Das Bundle wird ausschließlich über Ihren eigenen Static Storage / CDN ausgeliefert (z. B. /static/js/app-[hash].min.js). Niemals über externe Drittanbieter-URLs.

2. Standard Minification statt schwerer Obfuscation

Einsatz moderner Build-Tools (Vite / esbuild / Terser). Schwere JavaScript-Obfuscatoren mit destruktiven Eval-Schleifen sind tabu, um Core Web Vitals und CISO-Auditierbarkeit zu schützen.

3. Strikte Namespace-Kapselung (IIFE)

Der Code läuft vollständig gekapselt in einer anonymen Funktionsabgrenzung. Es werden keine globalen Variablen auf dem window-Objekt registriert.

4. Relative Pfad-Adressierung

Alle API-Endpunkte werden relativ adressiert (z. B. /api/sec/verify). Keine hardcodierten Fremddomains oder externe Callback-URLs im Code.

Architekturvergleich: Drittanbieter vs. First-Party

Gegenüberstellung der regulatorischen und operativen Auswirkungen für Risikomanager und Compliance-Beauftragte:

Dimension Konventionelle Drittanbieter-Integration GAMPERLAB™ First-Party Referenzarchitektur
Wettbewerber-Sichtbarkeit Öffentlich — Jederzeit über Crawler und Tech-Scanner einsehbar. Zero-Attribution — Vollkommen unsichtbar, 0 extern auffindbare Tags.
Angreifer-Bypässe Hoch — Botnetze blockieren Drittanbieter-DNS selektiv. Resistent — First-Party Routen können nicht ohne Abbruch blockiert werden.
DORA Art. 12 Drittparteienrisiko Kritisch — Komplexe Supply-Chain-Abhängigkeit im Frontend. Souverän — Getrennter mTLS-Backchannel, autarke In-Flight Kontrolle.
Latenz im Zahlungsverkehr 50 bis 200 ms (externe Cloud-API Hops) < 0.26 ms (In-Memory Engine / VIX Peering)
Bankgeheimnis (§ 38 BWG) Datenübertragung an externe Server außerhalb des Bankennetzes. Keine Speicherung, keine Datenweitergabe, verschlüsseltes Backchannel-Transit.
Revisionssicherer Audit-Trail: Sowohl Sanction Sieve™ als auch Pattern Sieve™ protokollieren Screening-Ergebnisse in einem unveränderlichen, SHA-256 verketten Hash-Ledger. Jeder Prüfschritt ist für interne Revisoren und Aufsichtsbehörden sekundengenau nachvollziehbar.