Viele APEX-Anwendungen rufen OCI Object Storage, Generative AI oder andere Cloud-Dienste auf. Bisher mussten Teams dafür oft API-Schlüssel oder andere langlebige Zugangsdaten erstellen, sicher speichern und rechtzeitig rotieren. Oracle APEX 26.2 unterstützt Resource-Principal-Authentifizierung für ausgehende Webservice-Aufrufe. Die Datenbank authentifiziert sich damit als verwaltete Ressource gegenüber OCI; ein persönlicher Schlüssel muss nicht in der Anwendung hinterlegt werden.
Identität der Ressource statt Identität eines Benutzers
Ein Resource Principal repräsentiert den Datenbankdienst beziehungsweise eine über Database Tools Identity eingerichtete Schema-Identität. OCI IAM entscheidet über Dynamic Groups und Policies, auf welche Ressourcen diese Identität zugreifen darf. Das ist ein anderes Sicherheitsmodell als ein API-Key eines einzelnen IAM-Benutzers: Rechte werden an die Laufzeitressource gebunden und können nach dem Least-Privilege-Prinzip begrenzt werden.
Ein typischer Anwendungsfall ist eine APEX-Anwendung, die einen Dokumentendienst oder ein OCI-API aufruft. Für unterschiedliche Anwendungsschemas können getrennte Database Tools Identities eingerichtet werden. So muss nicht jedes Schema denselben Cloud-Zugriff erben.
Vor dem ersten APEX-Aufruf planen
- Festlegen, welche Datenbank- oder Schema-Identität den OCI-Dienst aufrufen soll.
- In OCI eine passende Dynamic Group und eine eng begrenzte Policy für genau den benötigten Dienst und Scope definieren.
- Bei Database Tools Identity die Verbindung auf Resource Principal auslegen und die Identity dem richtigen Schema zuordnen.
- In APEX den unterstützten Webservice-Aufruf mit Resource Principal konfigurieren und zunächst einen read-only Test ausführen.
- Ergebnis, Identität und IAM-Auditdaten prüfen; Schreibrechte erst nach erfolgreichem Berechtigungs- und Recovery-Test ergänzen.
Fehler systematisch eingrenzen
Wenn ein Aufruf scheitert, prüfen Sie zuerst, welche Identität tatsächlich verwendet wird. Danach folgen Dynamic-Group-Regel, Policy-Scope und Compartment-Zuordnung. Erst wenn OCI die Anfrage autorisiert, lohnt die getrennte Prüfung von DNS, TLS, Netzwerk-ACL und Ziel-URL. Testen Sie den Aufruf aus dem APEX-Runtime-Kontext: Ein erfolgreicher Aufruf aus SQLcl unter einem persönlichen OCI-Profil beweist nicht, dass dieselbe Berechtigung auch für die Datenbank-Ressource gilt.
Resource Principals verschieben die Schlüsselpflege aus der Anwendung in eine verwaltete Identität. Der Sicherheitsgewinn entsteht durch präzise IAM-Regeln, getrennte Identitäten für unterschiedliche Aufgaben und einen Test, der den echten APEX-Laufzeitpfad abdeckt.
Weiterführend: Oracle APEX 26.2 Neuerungen und Resource-Principal-Unterstützung, Oracles Leitfaden zu Database Tools Identity und die Dokumentation zu Dynamic Groups.