Oracle Mobile Authenticator: MFA direkt für den Datenbank-Login

Benutzername und Passwort allein sind heute kein ausreichender Schutz für kritische Zugänge. Phishing und Credential-Stuffing zeigen, wie schnell reine Wissensfaktoren, also Kenntnisse wie Passwörter oder PINs, aushebelbar sind.

Dazu kommt, dass regulatorische Anforderungen nur noch strikter werden.

Oracle Mobile Authenticator (OMA) setzt genau an dieser Stelle an: Dort, wo klassische Passwörter an ihre Grenzen kommen, ergänzt OMA den Login um einen zweiten Faktor innerhalb des Oracle-Ökosystems. In der Praxis wurden native Datenbankzugriffe bisher häufig über Passwortrichtlinien, Netzwerkbeschränkungen, VPN-Zugänge, Bastion-Hosts oder externe MFA- beziehungsweise Identity-Lösungen abgesichert. Diese Maßnahmen sind grundsätzlich sinnvoll, lösen aber nicht immer das Kernproblem: Der eigentliche Datenbank-Login bleibt häufig weiterhin stark vom Passwort abhängig oder erfordert zusätzliche Infrastruktur außerhalb der Oracle-Welt.

OMA kann hier eine schlankere Alternative darstellen. Der zweite Faktor wird direkt in den Oracle-Kontext eingebunden, ohne dass zwingend ein weiterer Drittanbieter, zusätzliche Verträge oder eine separate MFA-Plattform benötigt werden. Gerade für native Datenbank-Logins ist das attraktiv, weil sich MFA nicht nur vor Anwendungen oder Portale schalten lässt, sondern näher am eigentlichen Zugriff auf die Datenbank ansetzt.

Für wen ist OMA?

Die Multi-Faktor-Authentifizierung mit OMA ist vor allem für interaktive Datenbank-Logins gedacht – also für Situationen, in denen sich eine Person bewusst an der Oracle-Datenbank anmeldet und den Zugriff aktiv bestätigen kann. Typische Beispiele sind Administrator:innen, Power User, Analyst:innen oder Entwickler:innen, die sich über SQL*Plus, SQLcl, SQL Developer oder vergleichbare Clients anmelden. Im Fokus stehen dabei lokale Datenbankbenutzer:innen, deren Authentifizierung direkt durch die Oracle-Datenbank erfolgt.

Für technische oder indirekte Zugriffsmuster ist OMA hingegen nicht der passende Ansatz. Dazu zählen beispielsweise Anwendungsbenutzer:innen, Server-zu-Server-Verbindungen, zentral verwaltete Benutzer:innen über CMU, Real Application Security (RAS)-Benutzer:innen oder Rollenpasswörter. In diesen Fällen greifen andere Sicherheitsmechanismen besser – etwa eine zentrale Identity-Integration, Netzwerksegmentierung, Zertifikate, Secrets Management, RADIUS-Integrationen oder MFA-Konzepte auf Applikations- beziehungsweise Identity-Ebene.

Damit unterscheidet sich OMA bewusst von klassischen MFA-Ansätzen, die häufig vor Anwendungen, Portale oder zentrale Identity Provider geschaltet werden. Lösungen wie Microsoft Entra ID, früher häufig Azure AD genannt, spielen ihre Stärken besonders dann aus, wenn Zugriffe über Entra ID, Webanwendungen oder zentral verwaltete Identitäten gesteuert werden.

Das Feature ist ab dem Release Update Oracle Database 26ai (26.9) verfügbar und wurde mit dem Juli Release Update 2025 auf Oracle Database 19c zurückportiert. Die OMA-App ist dabei auf allen gängigen Mobilgeräten verfügbar.

Wie ist es für Benutzer:innen?

Benutzer:innen beginnen den Login-Prozess mit ihren Zugangsdaten, also Benutzername und Passwort, wie gewohnt an der Kommandozeile oder dem GUI-Tool. Ob für lokale Datenbankbenutzer:innen MFA aktiviert ist, wird in der jeweiligen PDB anhand der Benutzerkonfiguration geprüft. Relevant ist also nicht eine globale Einstellung im CDB-Root, sondern die Authentifizierungskonfiguration der konkreten User innerhalb der PDB. Danach wird eine MFA-Anfrage an den Push Service gesendet, hier konkret Oracle Cloud IAM (Identity & Access Management). Kurz darauf erscheint eine Push-Benachrichtigung auf dem registrierten Mobilgerät der Benutzer:innen. Hier kann der Anmeldeversuch bestätigt oder abgelehnt werden. Wenn Benutzer:innen die Anfrage bestätigen, wird die Datenbank vom Push-Service informiert und eine Session für sie gestartet. Es braucht keine zusätzlichen Skripte oder Änderungen an der Software-Konfiguration des Clients.

Die Registrierung in der OMA-App ist für Benutzer:innen ebenso einfach. Nachdem Benutzer:innen von Administrator:innen angelegt wurden, bekommen sie eine standardisierte E-Mail. In dieser werden sie aufgefordert, einen QR-Code mithilfe der OMA-App zu scannen und damit ihr Mobilgerät zu registrieren. Sollten sie noch kein Passwort in der Oracle Cloud IAM haben, können sie dieses vergeben.

Was braucht ihr für die Konfiguration?

Bevor MFA eingerichtet werden kann, müssen die Voraussetzungen auf OCI-IAM-Seite geschaffen und die erforderlichen Konfigurationen auf Datenbankebene vorgenommen werden.

Zunächst muss die Registrierung des Push Services durchgeführt werden. Dafür ist ein OCI IAM Account zwingend notwendig. Dafür bietet Oracle kostenfreie sowie kostenpflichtige Stufen an. Damit die Datenbank im OCI IAM authentifiziert wird, muss eine OAuth-Applikation registriert werden.

Dabei ist es wichtig, sie als Client zu konfigurieren und bei der Autorisierungsmethode den Typ Client Credentials zu wählen. Damit lassen sich Client ID und Client Secret generieren. Damit die OAuth-Applikation Benutzer:innen anlegen kann und Zugriff auf die MFA-REST-Schnittstelle bekommt, müssen die Rollen „MFA Client“ und „User Administrator“ vergeben werden. Neben der Client ID und dem Client Secret ist noch die Domain URL wichtig, da sie für die Konfiguration auf Datenbank-Ebene gebraucht werden.

Damit Benutzer:innen registriert werden können, ist eine E‑Mail‑Integration vorausgesetzt. Dafür kann z. B. ein SMTP‑Server des Unternehmens über einen SMTP‑Endpunkt angebunden werden oder der E‑Mail‑Delivery‑Service der OCI verwendet werden. Wichtige Informationen diesbezüglich sind: der SMTP‑Public‑Endpoint sowie der zu verwendende Port und die Benutzerdaten der/des SMTP‑Benutzer:in, also Benutzername und Passwort.

Wie muss die Datenbank konfiguriert werden?

Um die Zugangsdaten der OAuth-Applikation und die der/des SMTP-Benutzer:in zu speichern, wird ein Wallet benötigt. Dabei ist es wichtig, den Wallet im korrekten Verzeichnis zu erstellen. Für eine Pluggable Database muss das Verzeichnis wie folgt angegeben werden:

<Wallet>/<PDB-GUID>/mfa

Wenn die MFA für administrative Benutzer:innen verwendet werden soll, muss das Wallet auch für die CDB eingerichtet werden. Das Verzeichnis dafür ist:

<Wallet>/mfa

Konkret könnte die Erstellung des Wallets so aussehen:

Danach müssen die Secrets im Wallet hinterlegt werden.

Als nächstes müssen einige wenige Parameter auf PDB-Ebene gesetzt werden.

Die Absender‑E‑Mail‑Adresse muss nicht der E‑Mail‑Adresse der/des SMTP‑Benutzer:in entsprechen. Es muss lediglich eine syntaktisch korrekte E‑Mail‑Adresse angegeben werden, die vom verwendeten SMTP‑Service akzeptiert wird. Wenn der E‑Mail‑Delivery‑Service der OCI verwendet wird, muss die hier angegebene Adresse zudem ein zugelassener Sender sein. Es empfiehlt sich, eine überwachte Adresse zu verwenden, damit Antworten oder Bounce‑Nachrichten das Team erreichen.

Ändert MFA die Benutzerverwaltung?

Mit MFA bleibt der Kernprozess unverändert. Es werden weiterhin Benutzer:innen, Passwörter und Berechtigungen vergeben. Neu sind der zweite Faktor und der externe Name als Eigenschaften der Benutzer:innen. Jede:r Benutzer:in hat dabei genau einen einzigartigen externen Namen. Es ist nicht möglich, dass zwei Benutzer:innen denselben externen Namen haben oder Benutzer:innen zwei externe Namen zugeordnet werden.

Die Erstellung von Benutzer:innen mit MFA kann wie folgt aussehen:

CREATE &user_name IDENTIFIED BY &user_password AND FACTOR 'OMA_PUSH' AS '&user_mail';

Ähnlich verhält es sich, wenn die MFA für bestehende Benutzer:innen hinzugefügt, gelöscht oder aktualisiert werden muss.

Im Zuge der Löschung von Benutzer:innen kommt es in der OCI IAM zu zusätzlichem Aufwand, da sie nicht automatisch gelöscht werden.

Die Vor- und Nachteile auf einen Blick!

Vorteile:

Das Sicherheitsniveau, mit einer explizierten Bestätigung am Endgerät, ist gegenüber Passwort-Only deutlich erhöht.
Die Benutzer-Experience ist unkompliziert; kein Abtippen von lästigen Codes.
Die Migration von Benutzer:innen kann granular erfolgen für ein entspannteres Rollout.
Es sind keine Updates oder Softwareinstallationen auf Clients notwendig.
Einfache Konfiguration

Nachteile:

Eingeschränkter Anwendungsbereich; nicht geeignet für Anwendungsbenutzer:innen, CMU, RAS oder Server-zu-Server-Verbindungen
Abhängigkeit und Konfigurationsaufwand in OCI
Registrierungsmails derzeit nur auf Englisch und nur eingeschränkt anpassbar

Fazit

Mit Oracle Mobile Authenticator erweitert Oracle seine Datenbankplattform um eine native MFA-Lösung für interaktive Anmeldungen. Während Datenbankzugriffe bislang häufig über externe MFA-Systeme, RADIUS-Integrationen oder vorgeschaltete Identity-Lösungen abgesichert wurden, bringt OMA den zweiten Faktor näher an den eigentlichen Datenbank-Login.

Die größten Stärken liegen in der einfachen Einführung und der nahtlosen Benutzererfahrung: Bestehende Clients können unverändert genutzt werden, Anwender:innen bestätigen die Anmeldung bequem per Push-Nachricht und die Aktivierung kann schrittweise pro Benutzer:in erfolgen. Für den klar definierten Anwendungsfall interaktiver Datenbank-Logins bietet OMA damit eine schlanke und praxisnahe Möglichkeit, die Sicherheit deutlich zu erhöhen, ohne zusätzliche Komplexität in die Umgebung zu bringen. Ihr plant Multi-Faktor-Authentifizierung für Oracle-Datenbanken? Wir beraten zu Architektur, Rollout und Betrieb. Kontaktiert uns.