Oracle APEX · · 3 Min.

APEX 26.2: Netzwerkzugriffe je Workspace begrenzen

Die neue Schema-ACL-Option trennt ausgehende APEX-Aufrufe stärker nach Parsing-Schema. Das verbessert Isolation, verlangt aber eine saubere Bestandsaufnahme der Integrationen.

In einer APEX-Instanz können viele Workspaces REST APIs, Mailserver oder externe Druckdienste aufrufen. Bisher liefen unterstützte ausgehende APEX-Netzwerkaufrufe standardmäßig über die Network ACL des zentralen APEX-Engine-Schemas. Eine Freigabe dort galt damit im Prinzip für Anwendungen der gesamten Instanz. APEX 26.2 ermöglicht eine feinere Trennung: Mit WEBSERVICE_USE_SCHEMA_ACL können unterstützte Aufrufe die ACL des aufrufenden Schemas verwenden.

Was die Einstellung bewirkt

Die Option ist ein Instanzparameter und steht standardmäßig auf N, sodass das bisherige Verhalten erhalten bleibt. Wird sie auf Y gesetzt, muss das jeweilige Parsing-Schema die benötigten Netzwerkrechte besitzen. So kann etwa ein Workspace Zugriff auf einen bestimmten REST-Host erhalten, während ein anderer Workspace keine Verbindung zu diesem Ziel aufbauen darf.

BEGIN
  APEX_INSTANCE_ADMIN.SET_PARAMETER(
    p_parameter => 'WEBSERVICE_USE_SCHEMA_ACL',
    p_value     => 'Y');
  COMMIT;
END;
/

Die Änderung betrifft die APEX-Instanz. Deshalb zuerst vorhandene ausgehende Funktionen inventarisieren: REST Data Sources, Webservice-Aufrufe, Automations, Mail, Remote Printing und weitere Integrationen. Beachten Sie, dass bei mehreren Parsing-Schemas eines Workspaces die Rechte am tatsächlich aufrufenden Schema hängen.

ACLs je Schema gezielt vergeben

Geben Sie nur die benötigten Hosts und Ports frei. Ein Beispiel für eine Verbindung zu einem festgelegten API-Endpunkt:

BEGIN
  DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
    host       => 'api.example.com',
    lower_port => 443,
    upper_port => 443,
    ace        => xs$ace_type(
      privilege_list => xs$name_list('connect'),
      principal_name => 'APP_SCHEMA',
      principal_type => xs_acl.ptype_db));
END;
/

Vermeiden Sie pauschale Host-Wildcards, wenn eine konkrete Domain genügt. Die ACL regelt den Netzwerkzugriff des Datenbankschemas; sie ersetzt weder Authentifizierung am entfernten Dienst noch die Prüfung von Web Credentials, TLS und Anwendungsberechtigungen.

Kompatibilitätsgrenze: Oracle dokumentiert, dass Legacy-SOAP-Aufrufe nicht unterstützt werden, wenn WEBSERVICE_USE_SCHEMA_ACL aktiviert ist. Diese Anwendungen müssen vor dem Umschalten identifiziert und separat bewertet werden.

Rollout ohne Überraschungen

  1. APEX-Version und aktuelle Network ACLs der Engine- und Anwendungsschemas erfassen.
  2. Alle Workspaces und tatsächlich verwendeten Parsing-Schemas den ausgehenden Zielen zuordnen.
  3. Fehlende Host- und Portfreigaben eng begrenzt ergänzen.
  4. Den Parameter zunächst in einer Testinstanz aktivieren und REST, Mail, Druck sowie Jobs end-to-end prüfen.
  5. Fehlerprotokolle und ACL-Konfiguration nach dem Wechsel gemeinsam überwachen.

Die Funktion macht aus einer instanzweiten Vertrauenszone eine besser aufteilbare Richtlinie. Der Sicherheitsgewinn entsteht aber erst dann, wenn Berechtigungen pro Schema minimal vergeben und alle APEX-Aufrufpfade getestet werden. Besonders bei gemeinsam genutzten Schemas sollte klar dokumentiert sein, welche Anwendungen dieselben externen Ziele erreichen dürfen.

Weiterführend: Oracle APEX 26.2 Release Notes, die Anleitung zum Aktivieren von Netzwerkdiensten und die Parameterreferenz für WEBSERVICE_USE_SCHEMA_ACL.