Viele Anwendungen verbinden sich mit einem technischen Datenbankkonto. Das ist einfach, aber die Datenbank sieht zunächst nur dieses Konto – nicht die Anwendung oder den AI-Agenten, der die Verbindung tatsächlich nutzt. Oracle AI Database 26ai erweitert Oracle Deep Data Security um Application Identity Logon: Eine registrierte Anwendung kann sich mit ihrem eigenen IAM-basierten Datenbank-Token anmelden.
1. Application Identity registrieren
Die Datenbank ordnet eine Application Identity einem externen Client-Identifier zu. Je nach Identitätsanbieter kann das beispielsweise eine Microsoft-Entra-Client-ID oder eine OCI-IAM-Client-ID sein:
CREATE APPLICATION IDENTITY hcm_app
MAPPED TO 'IAM_OAUTH_CLIENT_ID=<client-id>';Für die Erstellung ist das Systemprivileg CREATE APPLICATION IDENTITY erforderlich. Vor dem produktiven Einsatz sollte die Zuordnung eindeutig dokumentiert und regelmäßig mit den IAM-Registrierungen abgeglichen werden. Die Datenbank stellt dafür unter anderem DBA_APPLICATION_IDENTITIES bereit.
2. Data Roles als Begrenzung
Die Application Identity kann lokale Data Roles erhalten. Diese Rollen enthalten die Datenberechtigungen, die die Anwendung oder der Agent im eigenen Autorisierungskontext aktivieren darf. Ein Beispiel:
GRANT DATA ROLE hcm_role TO hcm_app;Damit wird nicht automatisch ein vollständiger Schema-Zugriff erteilt. Die Rolle sollte nur die erforderlichen Views, Prozeduren oder Datenbereiche freigeben. Für einen Agenten ist ein kleines read-only Profil ein sinnvoller Start. Schreibende Aktionen gehören in eine eigene Rolle und sollten fachlich bestätigt und auditierbar sein.
3. Direkter Logon mit IAM
Eine IAM-verwaltete Anwendung oder ein AI-Agent registriert sich zunächst beim Identitätsanbieter und erhält über den Client-Credentials-Flow ein Datenbankzugriffs-Token. Die Datenbank validiert dieses Token und ordnet den Client der Application Identity zu. Die Verbindung erfolgt damit unter der Identität der Anwendung – ohne dass ein breit berechtigtes gemeinsames Passwortkonto der technische Mittelpunkt sein muss.
Die benötigten Token-Scope, Audience, TLS-Konfiguration und Datenbankparameter müssen zusammenpassen. Ein „gültiges“ IAM-Token genügt nicht, wenn es für die falsche Ressource ausgestellt wurde oder die Client-ID nicht zur Datenbankzuordnung passt.
4. Endnutzer und Agenten sauber unterscheiden
Ein Agent, der ausschließlich mit eigener Autorisierung arbeitet, ist ein anderer Fall als eine Anwendung, die im Auftrag vieler Endnutzer handelt. In der zweiten Variante muss zusätzlich der End-User-Security-Context übertragen und von der Datenbank durchgesetzt werden. Die Application Identity beschreibt dann die Anwendung, während die Endnutzer-Identität und ihre Rollen den konkreten Datenzugriff weiter einschränken.
Diese Trennung ist für Audit und Incident Response entscheidend: Im Log sollte erkennbar sein, welche Anwendung, welcher Nutzer und welcher Agent eine Aktion ausgelöst haben. Eine gemeinsame technische Identität ohne Kontext würde diesen Nachweis wieder abschwächen.
5. Sichere Einführungs-Checkliste
- IAM-Client, Datenbankressource, Token-Scope und TLS-Pfad festlegen.
- Application Identity mit eindeutiger Client-ID registrieren.
- Read-only Data Role mit kleinem Objektumfang anlegen und zuweisen.
- Direkten Logon in einer Testumgebung mit abgelaufenen und falschen Tokens prüfen.
- Audit für Application Identity, Endnutzer, Agent und SQL-Aktion einrichten.
- Schreibende Rollen getrennt freigeben und mit Review- und Rollback-Prozess betreiben.
Fazit
Application Identity Logon in Oracle AI Database 26ai verlagert die Identität von Anwendungen und AI-Agenten näher an die Datenbank. So lassen sich Zugriffe enger begrenzen und besser auditieren als mit einem einzigen technischen Konto. Der sichere Nutzen entsteht aber erst, wenn IAM, TLS, Data Roles, Endnutzerkontext und Monitoring als zusammenhängender Prozess geplant werden.
Weiterführend: Oracles Dokumentation zu Application Identities, die Anleitung für direkten IAM-Logon und die Datenbankkonfiguration für IAM.